From: user <wei.guo@ucloud.cn>
To: linux-nfs@vger.kernel.org, trond.myklebust@hammerspace.com,
anna@kernel.org
Subject: Re: [BUG] NFSv4.1 client hang in OPEN reclaim path (rpc_wait_bit_killable) on 5.15
Date: Wed, 25 Mar 2026 20:33:40 +0800 [thread overview]
Message-ID: <D54322C3-58CA-459A-A195-CE4511225ECB@ucloud.cn> (raw)
In-Reply-To: <538B06AD-0307-4BD4-8E44-16BF6BAD7B4E@ucloud.cn>
Server-side logs indicate that the client is sending stale stateids / sequence IDs, and the server responds with NFS4ERR_OLD_STATEID.
This suggests that the client state may not be properly updated after previous operations.
> 2026年3月25日 下午8:11，user <wei.guo@ucloud.cn> 写道：
>
> Hi,
>
> I hope you are doing well.
>
> We are currently investigating an issue with an NFSv4.1 client on Linux kernel 5.15 (Ubuntu 22.04), and would really appreciate your guidance.
>
> The issue starts when the server returns NFS4ERR_EXPIRED. The client appears to enter recovery, but the reclaim process does not complete.
>
> The state manager thread is observed to be stuck with the following stack:
>
> rpc_wait_bit_killable
> __rpc_wait_for_completion_task
> nfs4_run_open_task
> nfs4_open_recover_helper
> nfs4_open_recover
> nfs4_do_open_expired
> nfs40_open_expired
> __nfs4_reclaim_open_state
> nfs4_reclaim_open_state
> nfs4_do_reclaim
> nfs4_state_manager
>
> During this time:
> - The server continues to return NFS4ERR_EXPIRED
> - The client does not appear to successfully reclaim state
> - IO operations continue but repeatedly fail
>
> From RPC statistics:
> - ~30 million calls have been made
> - retransmissions are very low (94)
>
> This seems to suggest that the issue may not be caused by network loss or server unresponsiveness.
>
> Additionally, from our observations:
> - Network connectivity appears stable
> - The NFS server seems to be operating normally (no restart or failover observed)
>
> One detail that we found particularly interesting is that:
> - We do observe ongoing RENEW / SEQUENCE-related traffic from the client
> - However, the client still eventually encounters NFS4ERR_EXPIRED
>
> This makes us wonder whether lease renewal might not be effectively taking place, even though related traffic is being sent.
>
> Given that we are using NFSv4.1 (where lease renewal is implicit via SEQUENCE operations), we would greatly appreciate any insights on the following:
>
> 1. Under what conditions might a client still hit NFS4ERR_EXPIRED despite ongoing SEQUENCE activity and a seemingly healthy server/network?
> 2. Could there be scenarios where RPC completion, session slot handling, or sequence handling prevents the lease from being properly renewed?
> 3. Is this behavior something that has been observed before in the NFSv4.1 recovery or session handling paths, particularly in 5.15?
>
> At the moment, it looks like the client is stuck in the OPEN reclaim path waiting for RPC completion, and recovery is unable to make forward progress.
>
> If there are any known fixes or relevant patches in newer kernels (e.g., 5.19 or 6.x), we would also be very interested to learn about them.
>
> Thank you very much for your time and for any suggestions you may have.
>
> Best regards,
>
prev parent reply other threads:[~2026-03-25 12:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 12:11 [BUG] NFSv4.1 client hang in OPEN reclaim path (rpc_wait_bit_killable) on 5.15 user
2026-03-25 12:33 ` user [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D54322C3-58CA-459A-A195-CE4511225ECB@ucloud.cn \
--to=wei.guo@ucloud.cn \
--cc=anna@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).