From: Anna Schumaker <anna.schumaker@oracle.com>
To: Trond Myklebust <trondmy@kernel.org>,
"hch@infradead.ori" <hch@infradead.org>
Cc: "anna@kernel.org" <anna@kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] NFS: Fix directory delegation verifier checks
Date: Wed, 7 Jan 2026 11:52:49 -0500 [thread overview]
Message-ID: <0bc24199-7e23-4419-bc70-17ad4bebd690@oracle.com> (raw)
In-Reply-To: <d8ddd23a18985ae360855931f185d0e24c466310.camel@kernel.org>
Hi Trond,
On 1/7/26 10:07 AM, Trond Myklebust wrote:
> On Tue, 2026-01-06 at 21:23 -0800, hch@infradead.ori wrote:
>> On Tue, Jan 06, 2026 at 01:32:54PM -0500, Trond Myklebust wrote:
>>> Sigh... One last patch on top of all the previous ones, but if we
>>> hit
>>> another issue I think we need to consider just disabling directory
>>> delegations on the client until all the remaining issues can be
>>> fixed
>>> in the next release.
>>
>> This still crasheѕ generic/633:
>>
>> generic/633 4s ... [ 73.075526] run fstests generic/633 at 2026-
>> 01-07 05:21:37
>> [ 73.286318] process 'vfstest' launched '/dev/fd/4/file1' with NULL
>> argv: empty string added
>> [ 73.314625] Oops: general protection fault, probably for non-
>> canonical address 0xcccccccccccccd50: 0000 [#1] SMP NOPTI
>> [ 73.315391] CPU: 1 UID: 0 PID: 100 Comm: kworker/u8:3 Tainted:
>> G N 6.19.0-rc4+ #4540 PREEMPT(full)
>> [ 73.316043] Tainted: [N]=TEST
>> [ 73.316229] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS 1.16.3-debian-1.16.3-2 04/01/2014
>> [ 73.316786] Workqueue: rpciod rpc_async_schedule
>> [ 73.317066] RIP: 0010:nfs_inode_find_state_and_recover+0x9c/0x260
>> [ 73.317430] Code: 01 0f 85 83 00 00 00 49 8b 84 24 80 00 00 00 4c
>> 8d 60 80 48 39 c3 0f 84 68 01 00 00 4d 8b 7c 24 60 4d 85 ff 74 e1 48
>> 8b 7d 00 <49> 39 bf 84 00 00 00 75 af 8b 4d 08 41 39 8f 8c 00 00 00
>> 75 a3 48
>> [ 73.318513] RSP: 0018:ffffc900001bfd00 EFLAGS: 00010286
>> [ 73.318868] RAX: ffff88810cfb98e0 RBX: ffff8881d68d8c50 RCX:
>> 0000000000000000
>> [ 73.319354] RDX: ffff88810330a0c0 RSI: ffff88811a86d914 RDI:
>> b6162427695ded30
>> [ 73.319832] RBP: ffff88811a86d918 R08: ffff88810c685100 R09:
>> ffff88810c685130
>> [ 73.320270] R10: 0000000000000003 R11: fefefefefefefeff R12:
>> ffff88810cfb9860
>> [ 73.320698] R13: ffff8881179b2800 R14: 0000000000000000 R15:
>> cccccccccccccccc
>> [ 73.321135] FS: 0000000000000000(0000) GS:ffff8882b363d000(0000)
>> knlGS:0000000000000000
>> [ 73.321640] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 73.321994] CR2: 0000559277cef238 CR3: 0000000161792002 CR4:
>> 0000000000772ef0
>> [ 73.322422] PKRU: 55555554
>> [ 73.322592] Call Trace:
>> [ 73.322749] <TASK>
>> [ 73.322889] nfs4_delegreturn_done+0x1b7/0x380
>> [ 73.323173] ? __pfx_rpc_exit_task+0x10/0x10
>> [ 73.323475] rpc_exit_task+0x5c/0x170
>> [ 73.323755] __rpc_execute+0xb1/0x490
>> [ 73.324000] rpc_async_schedule+0x2a/0x40
>> [ 73.324257] process_one_work+0x16c/0x330
>> [ 73.324515] worker_thread+0x254/0x3a0
>> [ 73.324762] ? __pfx_worker_thread+0x10/0x10
>> [ 73.325042] kthread+0x117/0x230
>> [ 73.325303] ? __pfx_kthread+0x10/0x10
>> [ 73.325557] ? __pfx_kthread+0x10/0x10
>> [ 73.325812] ret_from_fork+0x1b6/0x200
>> [ 73.326045] ? __pfx_kthread+0x10/0x10
>> [ 73.326278] ret_from_fork_asm+0x1a/0x30
>> [ 73.326535] </TASK>
>> [ 73.326681] Modules linked in: kvm_intel kvm irqbypass
>> [ 73.327046] ---[ end trace 0000000000000000 ]---
>
> Thanks for doing all this testing, Christoph. I really appreciate it.
> The previous patch was incomplete. This is incremental to yesterday's
> patch, but I'll squash them together in the testing branch, since
> they're both about blocking state recovery in the non-regular file
> case.
>
> 8<-----------------------------------------------------------------
> From 534676d290af6fae6ad1b067b81c13523340bc83 Mon Sep 17 00:00:00 2001
> Message-ID: <534676d290af6fae6ad1b067b81c13523340bc83.1767798220.git.trond.myklebust@hammerspace.com>
> From: Trond Myklebust <trond.myklebust@hammerspace.com>
> Date: Wed, 7 Jan 2026 10:01:58 -0500
> Subject: [PATCH] NFSv4.x: Directory delegations don't require any state
> recovery (part 2)
>
> This patch will be squashed with part 1.
I finally hit Christoph's crasher this morning, and this patch did
help when running with NFS v4.1 but I still see the problem with v4.2.
I haven't dug into it enough to know if it's just harder to hit now,
though.
Do you want me to take back over debugging this from here?
Anna
>
> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> ---
> fs/nfs/nfs4state.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
> index 01179f7de322..dba51c622cf3 100644
> --- a/fs/nfs/nfs4state.c
> +++ b/fs/nfs/nfs4state.c
> @@ -1445,6 +1445,8 @@ void nfs_inode_find_state_and_recover(struct inode *inode,
> struct nfs4_state *state;
> bool found = false;
>
> + if (!S_ISREG(inode->i_mode))
> + goto out;
> rcu_read_lock();
> list_for_each_entry_rcu(ctx, &nfsi->open_files, list) {
> state = ctx->state;
> @@ -1466,7 +1468,7 @@ void nfs_inode_find_state_and_recover(struct inode *inode,
> found = true;
> }
> rcu_read_unlock();
> -
> +out:
> nfs_inode_find_delegation_state_and_recover(inode, stateid);
> if (found)
> nfs4_schedule_state_manager(clp);
> @@ -1478,6 +1480,8 @@ static void nfs4_state_mark_open_context_bad(struct nfs4_state *state, int err)
> struct nfs_inode *nfsi = NFS_I(inode);
> struct nfs_open_context *ctx;
>
> + if (!S_ISREG(inode->i_mode))
> + return;
> rcu_read_lock();
> list_for_each_entry_rcu(ctx, &nfsi->open_files, list) {
> if (ctx->state != state)
next prev parent reply other threads:[~2026-01-07 16:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 20:13 [PATCH] NFS: Fix directory delegation verifier checks Anna Schumaker
2025-12-22 22:35 ` Christoph Hellwig
2025-12-23 1:06 ` Christoph Hellwig
2025-12-31 21:52 ` Trond Myklebust
2026-01-06 6:21 ` hch@infradead.ori
2026-01-06 18:32 ` Trond Myklebust
2026-01-07 5:23 ` hch@infradead.ori
2026-01-07 15:07 ` Trond Myklebust
2026-01-07 15:30 ` hch@infradead.ori
2026-01-08 9:23 ` hch@infradead.ori
2026-01-07 16:52 ` Anna Schumaker [this message]
2026-04-04 18:32 ` Al Viro
2026-04-04 19:07 ` Al Viro
2026-04-05 2:39 ` Al Viro
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=0bc24199-7e23-4419-bc70-17ad4bebd690@oracle.com \
--to=anna.schumaker@oracle.com \
--cc=anna@kernel.org \
--cc=hch@infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@kernel.org \
/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).