[PATCH AUTOSEL 6.17-5.4] nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing

[PATCH AUTOSEL 6.17-5.4] nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing

[Sasha Levin]

From: Al Viro <viro@zeniv.linux.org.uk>

[ Upstream commit a890a2e339b929dbd843328f9a92a1625404fe63 ]

Theoretically it's an oopsable race, but I don't believe one can manage
to hit it on real hardware; might become doable on a KVM, but it still
won't be easy to attack.

Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of
put_unaligned_be64(), we can put that under ->d_lock and be done with that.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
- The race is in `fs/nfs/nfs4proc.c:395`, where
  `NFS_FILEID(d_inode(dentry->d_parent))` relied on `d_parent` staying
  stable while another thread might be executing `__d_move`/rename and
  mutating that field under `dentry->d_lock`. Without taking that lock
  we can observe a transient or freed `d_parent`, leading to an oops
  while synthesising the “..” entry during readdir.
- The fix simply wraps the dereference in `spin_lock(&dentry->d_lock)` /
  `spin_unlock(&dentry->d_lock)` (`fs/nfs/nfs4proc.c:394-396`), matching
  dcache locking rules so we never race with rename/unhash. The critical
  section only covers `xdr_encode_hyper` (a `put_unaligned_be64`), so
  there is virtually no new latency or deadlock risk.
- No behavioural changes beyond closing this bug: the rest of
  `nfs4_setup_readdir()` is untouched, there are no dependency patches
  required, and this aligns with the long-standing expectation that
  anyone walking `d_parent` holds the dentry lock.
- Because the bug can crash clients performing `readdir()` while
  directories are being renamed/unlinked—even if the window is
  narrow—this is a correctness fix with minimal risk and well within the
  stable backport guidelines.

 fs/nfs/nfs4proc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 4de3e4bd724b7..b76da06864e53 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -391,7 +391,9 @@ static void nfs4_setup_readdir(u64 cookie, __be32 *verifier, struct dentry *dent
 	*p++ = htonl(attrs);                           /* bitmap */
 	*p++ = htonl(12);             /* attribute buffer length */
 	*p++ = htonl(NF4DIR);
+	spin_lock(&dentry->d_lock);
 	p = xdr_encode_hyper(p, NFS_FILEID(d_inode(dentry->d_parent)));
+	spin_unlock(&dentry->d_lock);
 
 	readdir->pgbase = (char *)p - (char *)start;
 	readdir->count -= readdir->pgbase;
-- 
2.51.0

[PATCH AUTOSEL 6.17-5.4] NFSv4.1: fix mount hang after CREATE_SESSION failure

[Sasha Levin]

From: Anthony Iliopoulos <ailiop@suse.com>

[ Upstream commit bf75ad096820fee5da40e671ebb32de725a1c417 ]

When client initialization goes through server trunking discovery, it
schedules the state manager and then sleeps waiting for nfs_client
initialization completion.

The state manager can fail during state recovery, and specifically in
lease establishment as nfs41_init_clientid() will bail out in case of
errors returned from nfs4_proc_create_session(), without ever marking
the client ready. The session creation can fail for a variety of reasons
e.g. during backchannel parameter negotiation, with status -EINVAL.

The error status will propagate all the way to the nfs4_state_manager
but the client status will not be marked, and thus the mount process
will remain blocked waiting.

Fix it by adding -EINVAL error handling to nfs4_state_manager().

Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
- Trunking discovery marks the client as `NFS_CS_SESSION_INITING`
  (`fs/nfs/nfs4client.c:391`) and the mount thread waits for
  `nfs_mark_client_ready()` to transition the state
  (`fs/nfs/client.c:376`). When `nfs4_proc_create_session()` aborts with
  `-EINVAL`—for example because the server rejects backchannel
  parameters in `nfs4_verify_back_channel_attrs()`
  (`fs/nfs/nfs4proc.c:9438`)—`nfs41_init_clientid()` returns before the
  ready-state update (`fs/nfs/nfs4state.c:332`), leaving the waiter
  blocked forever.
- The patch adds a dedicated `case -EINVAL` that forwards the failure to
  `nfs_mark_client_ready(clp, status)` (`fs/nfs/nfs4state.c:2747`,
  `fs/nfs/nfs4state.c:2748`), matching the existing handling of fatal
  network errors at `fs/nfs/nfs4state.c:2743`. This immediately wakes
  waiters so the mount fails cleanly instead of hanging.
- The bug is high-impact: affected clients hang indefinitely after
  CREATE_SESSION negotiation failures, preventing mount completion.
  Delivering the real error to user space satisfies the stable tree goal
  of fixing serious user-visible regressions.
- Risk is low: the change is limited to a single switch arm, introduces
  no new code paths on success, and relies on long-standing semantics
  that allow marking the client ready with negative states
  (`fs/nfs/client.c:458`).

- Next step: queue this fix for all supported stable NFSv4.1 branches so
  mounts no longer stall on CREATE_SESSION negotiation failures.

 fs/nfs/nfs4state.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 7612e977e80b5..01179f7de3225 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -2744,6 +2744,9 @@ static void nfs4_state_manager(struct nfs_client *clp)
 	case -ENETUNREACH:
 		nfs_mark_client_ready(clp, -EIO);
 		break;
+	case -EINVAL:
+		nfs_mark_client_ready(clp, status);
+		break;
 	default:
 		ssleep(1);
 		break;
-- 
2.51.0

[PATCH AUTOSEL 6.17-5.4] NFSv4: handle ERR_GRACE on delegation recalls

[Sasha Levin]

From: Olga Kornievskaia <okorniev@redhat.com>

[ Upstream commit be390f95242785adbf37d7b8a5101dd2f2ba891b ]

RFC7530 states that clients should be prepared for the return of
NFS4ERR_GRACE errors for non-reclaim lock and I/O requests.

Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
**Key Points**
- The change at `fs/nfs/nfs4proc.c:7876-7880` extends the recall retry
  loop so that `-NFS4ERR_GRACE` is treated exactly like
  `-NFS4ERR_DELAY`, matching RFC 7530’s requirement that non-reclaim
  requests retry during the server’s grace period; without it we
  prematurely exit the loop.
- When the old code bailed out on `-NFS4ERR_GRACE`, control returned up
  the stack, causing `nfs_delegation_claim_locks()` to propagate
  `-EAGAIN` (`fs/nfs/delegation.c:176-178`), which in turn made
  `nfs_end_delegation_return()` fall into the client-recovery path or
  abort the delegation (`fs/nfs/delegation.c:584-596`), disrupting
  otherwise healthy delegations after a server restart.
- Other lock paths already retry on `-NFS4ERR_GRACE` (see
  `fs/nfs/nfs4proc.c:7594-7604`), so this patch simply aligns the
  delegation-recall path with existing, well-tested behaviour and
  prevents unnecessary recovery storms.
- The fix is tiny, localized to the NFS client delegation logic, and
  carries minimal regression risk while addressing a real-world failure
  mode observed during grace periods; it is an ideal candidate for
  stable backporting.

 fs/nfs/nfs4proc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 611e6283c194f..4de3e4bd724b7 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -7872,10 +7872,10 @@ int nfs4_lock_delegation_recall(struct file_lock *fl, struct nfs4_state *state,
 		return err;
 	do {
 		err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
-		if (err != -NFS4ERR_DELAY)
+		if (err != -NFS4ERR_DELAY && err != -NFS4ERR_GRACE)
 			break;
 		ssleep(1);
-	} while (err == -NFS4ERR_DELAY);
+	} while (err == -NFS4ERR_DELAY || err == -NFSERR_GRACE);
 	return nfs4_handle_delegation_recall_error(server, state, stateid, fl, err);
 }
 
-- 
2.51.0