From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E674E289E23; Fri, 6 Jun 2025 15:42:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749224553; cv=none; b=cC+C2SrtnBL8r8DMhN85cqazAl2Tdn0mJSwmTld+ETSFip65yd8DY5TwDKzfHPOEZ84m2Fmqeo7XBFWM1MSuuwK/NOkAxMXVBwczbAJ20DcJOEE61rVmSh3/kxsg9pP1viT4lTZUcSTafLRteAJEswnWwhxZ9OpWpmLVUB2/5Tk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749224553; c=relaxed/simple; bh=GNhp/OFVEyqdKPrWBtDxirglDPwhP2RviNfwKcCBmfI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=hnebtHM5ML2FojqEXKb09E1GcE7fLcN2HNdf3v20ERvbpB7+LH7EvBEb1KxXjWpcDLGCbiv0+brRCUct5j+wei8eIyV1ElKbWGsXQT3dgD3gZ77h5lleAf4um851qfScXEenjhvl33USzpAh2olkeFKpbDWvzm3t0oCMIQHFHVQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X8uJ7mey; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X8uJ7mey" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75A17C4CEF0; Fri, 6 Jun 2025 15:42:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749224552; bh=GNhp/OFVEyqdKPrWBtDxirglDPwhP2RviNfwKcCBmfI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X8uJ7meyDfMzNpda4quaHD/yGLd0JcCCx8cfDCL1MIs8FRPOmkvwAoFb+/se9vjZM YbtO4Lzss2BaMmpuaS0bftcUu5UWzY+kcn6yndTkUC59e/EOtk4XmAPF+26r0/cuYX KiKXn73DM9zHF9GIlH2wYw0U5KZPERaqU/CFNakysWWY8MMpRiaIA3RPSQuBTwzFd8 3axIRW1xJ0rm/bwGYEQGk9xaMt6FD/Ly1wyxHzn1fhAxCt6K50yCOv278t2HAHde56 z/avtu9KYhI3IpGUhE0dRwrQdLbeoZI7FPS/YMgOUF6xhlq+iNM6E6rA7F+aY1aTW0 DIAjCn+PzPatw== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Han Young , Anna Schumaker , Sasha Levin , trondmy@kernel.org, anna@kernel.org, linux-nfs@vger.kernel.org Subject: [PATCH AUTOSEL 6.14 04/19] NFSv4: Always set NLINK even if the server doesn't support it Date: Fri, 6 Jun 2025 11:42:10 -0400 Message-Id: <20250606154225.546969-4-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250606154225.546969-1-sashal@kernel.org> References: <20250606154225.546969-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.14.10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Han Young [ Upstream commit 3a3065352f73381d3a1aa0ccab44aec3a5a9b365 ] fattr4_numlinks is a recommended attribute, so the client should emulate it even if the server doesn't support it. In decode_attr_nlink function in nfs4xdr.c, nlink is initialized to 1. However, this default value isn't set to the inode due to the check in nfs_fhget. So if the server doesn't support numlinks, inode's nlink will be zero, the mount will fail with error "Stale file handle". Set the nlink to 1 if the server doesn't support it. Signed-off-by: Han Young Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin --- Based on my analysis of the commit and the kernel source code, here is my determination: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Critical Bug Fix Analysis ### 1. **Root Cause Understanding** The commit addresses a critical issue where NFSv4 mounts fail with "Stale file handle" errors when the server doesn't support the `fattr4_numlinks` (NLINK) attribute. Looking at the code: - In `/home/sasha/linux/fs/nfs/nfs4xdr.c:3969`, the `decode_attr_nlink` function initializes `*nlink = 1` as a default - However, in `/home/sasha/linux/fs/nfs/inode.c:556-559`, the current logic only sets the inode's nlink if `fattr->valid & NFS_ATTR_FATTR_NLINK` is true - When the server doesn't support numlinks, the `fattr->valid` flag isn't set, so the inode's nlink remains 0 (from initial inode allocation) ### 2. **Impact of Zero nlink** From `/home/sasha/linux/fs/nfs/dir.c:1578-1582`, I can see the critical check: ```c if (inode->i_nlink > 0 || (inode->i_nlink == 0 && test_bit(NFS_INO_PRESERVE_UNLINKED, &NFS_I(inode)->flags))) return 0; else return -ESTALE; ``` When `i_nlink == 0` and the `NFS_INO_PRESERVE_UNLINKED` flag isn't set, NFS returns `-ESTALE`, causing "Stale file handle" errors and mount failures. ### 3. **Backport Suitability Criteria** **✅ Fixes important user-affecting bug**: Mount failures prevent basic filesystem functionality **✅ Small and contained fix**: The change adds only 2 lines: ```c else if (fattr_supported & NFS_ATTR_FATTR_NLINK) nfs_set_cache_invalid(inode, NFS_INO_INVALID_NLINK); +else + set_nlink(inode, 1); ``` **✅ Minimal regression risk**: Setting nlink=1 as fallback is safe and follows the NFSv4 spec (fattr4_numlinks is a "recommended" attribute, so emulation is appropriate) **✅ No architectural changes**: This is a targeted fix within existing error handling logic **✅ Follows stable tree rules**: It's an important bugfix with minimal risk ### 4. **Comparison with Similar Commits** Unlike the provided similar commits that were marked "NO" (which involved more complex nlink management, cache invalidation changes, or feature additions), this commit: - Fixes a fundamental compatibility issue - Prevents complete mount failures - Is minimal and defensive - Addresses server interoperability problems ### 5. **Server Compatibility** This fix ensures NFSv4 clients remain functional with servers that don't fully implement all recommended attributes, which is critical for real-world deployments where server implementations vary. The commit directly prevents mount failures that would otherwise require server-side fixes or workarounds, making it essential for stable kernel trees where users expect reliable NFS functionality. fs/nfs/inode.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c index 119e447758b99..4695292378bbe 100644 --- a/fs/nfs/inode.c +++ b/fs/nfs/inode.c @@ -557,6 +557,8 @@ nfs_fhget(struct super_block *sb, struct nfs_fh *fh, struct nfs_fattr *fattr) set_nlink(inode, fattr->nlink); else if (fattr_supported & NFS_ATTR_FATTR_NLINK) nfs_set_cache_invalid(inode, NFS_INO_INVALID_NLINK); + else + set_nlink(inode, 1); if (fattr->valid & NFS_ATTR_FATTR_OWNER) inode->i_uid = fattr->uid; else if (fattr_supported & NFS_ATTR_FATTR_OWNER) -- 2.39.5