mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Schubert <schubert@iap-kborn.de>
To: 郭玲兴 <guolingxing@supcon.com>, "Rick Macklem" <rick.macklem@gmail.com>
Cc: Lionel Cons <lionelcons1972@gmail.com>,
	linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] NFSv4.1 client hang in nfs4_drain_slot_tbl under concurrent workload against Windows NFS server
Date: Mon, 26 Oct 2026 08:45:54 +0100	[thread overview]
Message-ID: <9a8d698b-afd4-41a2-98f6-e062d33d71ff@iap-kborn.de> (raw)
In-Reply-To: <552f72d1.1c692.19e389e8ea4.Coremail.guolingxing@supcon.com>


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 performed one additional recovery test before rebooting the affected 
client.
On Windows, the affected client still existed with |TotalSessions=0|, 
but no session or open files.
We explicitly ran |Revoke-NfsMountedClient|for that client ID. The 
client record disappeared completely on the server.
More than one 120-second NFSv4.1 lease period later, Windows still had 
no client/session for that host, while the Linux NFS state-manager 
remained blocked in |nfs4_drain_slot_tbl|and did not create a new session.
This suggests that once the client reaches this state, removing all 
server-side client/session state does not trigger recovery; the Linux 
client remains stuck waiting on its old local session state.

Regards,
Peter Schubert


      parent reply	other threads:[~2026-10-26  7:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06  7:46 郭玲兴
2026-05-06 13:28 ` Lionel Cons
2026-05-07  0:50   ` 郭玲兴
2026-05-07  1:22     ` 郭玲兴
2026-05-16 14:23   ` Rick Macklem
2026-05-18  1:06     ` 郭玲兴
2026-10-22  7:50       ` Peter Schubert
2026-10-26  7:45       ` Peter Schubert [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=9a8d698b-afd4-41a2-98f6-e062d33d71ff@iap-kborn.de \
    --to=schubert@iap-kborn.de \
    --cc=guolingxing@supcon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lionelcons1972@gmail.com \
    --cc=rick.macklem@gmail.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

all inboxes | Powered by JetHome®