Re: [BUG] NFSv4.1 client hang in nfs4_drain_slot_tbl under concurrent workload against Windows NFS server

[Peter Schubert]

Am 18.05.2026 um 03:06 schrieb 郭玲兴:
>   Hi Rick, hi Lionel
>
> ...
>
> Regarding the "soft" mount option: understood. We will retest
> with a hard mount as well.
>
> One question is whether the observed behavior is expected.
> Even if a soft mount contributes to the problem, is it expected
> that a single RPC timeout can leave the client in a state with
> no forward progress, blocked in nfs4_drain_slot_tbl, and with
> lease renewal no longer occurring? Or would that more likely
> indicate a client-side recovery bug?
>
>
> Thanks,
> Guo Lingxing
Hi,

we have independently observed what appears to be the same NFSv4.1 
client hang against Microsoft Server for NFS, but with several important 
differences from the May 2026 report:

- the mounts are HARD, not soft
- sec=krb5 (RPCSEC_GSS), not AUTH_SYS
- observed on Linux 5.15 and Linux 6.8 clients
- Windows Server for NFS is from the Windows Server 2019 / build 17763 
family
- the trigger is strongly correlated with a Windows/NFS server restart, 
especially two rapid consecutive restarts during Windows servicing

Mount options:
  vers=4.1,rw,hard,timeo=1200,retrans=5,sec=krb5,proto=tcp

We currently have two affected clients preserved in the hung state.

Client A (Linux 5.15):
  nfsv4 SEQUENCE ... q:xprt_pending
  two nfsv4 GETATTR tasks ... q:ForeChannel Slot table

All of these use the same TCP transport to the Windows NFS server.

Client B (Linux 6.8):
  nfsv4 SEQUENCE ... q:xprt_pending

The NFS state-manager thread is blocked in:
  nfs4_drain_slot_tbl
  nfs4_reset_session
  nfs4_state_manager
  nfs4_run_state_manager

`lease_expired` continuously increases on the affected clients.

A 135-second tcpdump on Client B showed only TCP ACK packets between client
and server and no NFS RPC payload. The same SEQUENCE XID remained blocked on
q:xprt_pending before and after the capture.

Windows-side state at the same time:
- healthy Linux clients: TotalSessions=1 and an NFS session exists
- affected clients: the client record may still exist, but TotalSessions=0;
  Get-NfsSession and Get-NfsOpenFile return no objects
- one affected client is no longer listed by Get-NfsMountedClient at all,
  while the Linux client still waits on the stale local NFSv4.1 state

Historical correlation:
We have more than two independent incidents where the Windows NFS 
service/server was
restarted twice in rapid succession. In both cases one Linux client 
entered a
persistent abnormal NFS client state immediately afterwards. In the current
incident multiple Linux clients are affected while other clients recovered
normally.

This seems to indicate a client-side recovery deadlock: the server is 
back and
TCP is healthy, but the Linux client no longer sends useful NFS traffic 
because
a SEQUENCE/session slot never drains, and the state manager can wait 
indefinitely
in nfs4_drain_slot_tbl.

Questions:
1. Is there a known path where an outstanding NFSv4.1 SEQUENCE RPC can 
remain on
   xprt_pending while session recovery waits for the corresponding slot 
to drain?
2. Should nfs4_drain_slot_tbl be able to wait indefinitely in this 
situation?
3. When the server has lost the old session and is reachable again, 
should the
   client force teardown/recreation of the local session rather than 
waiting for
   the old slot forever?
4. Is there an existing patch or additional tracepoint/debug data that 
would be
   useful while we still have affected clients preserved in the hung state?

The May 2026 report appears closely related:
https://www.spinics.net/lists/kernel/msg6188959.html

We can provide the full SUNRPC debugfs output, mountstats, state-manager 
stacks,
Windows NFS session output, tcpdump, and timestamps of both server restart
incidents.

Regards,
Peter Schubert