From: Jeff Layton <jlayton@kernel.org>
To: Christian Brauner <brauner@kernel.org>, Chuck Lever <cel@kernel.org>
Cc: NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
Jan Kara <jack@suse.cz>,
linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: nfsd: delegated timestamps get written to frozen filesystems
Date: Sat, 14 Nov 2026 06:48:50 -0500 [thread overview]
Message-ID: <41522fcf40be21bb11409189204bb62ffac47ae4.camel@kernel.org> (raw)
In-Reply-To: <20261114-abdrehen-mahnwache-farbpalette-9c31774145cc@brauner>
On Sat, 2026-11-14 at 10:35 +0100, Christian Brauner wrote:
> Hey,
>
> I'm working on a freeze protection series. This fell out of it and I
> can't just fix it myself.
>
> Can I leave you with fixing this?
>
Yes. I'm currently working on a patchset to rework how delegated
timestamps are handled. I'll plan to roll some freeze protection into
the series (or in a trailing one if that's more suitable). No promises
on the timeframe though.
Cheers!
Jeff
> cb_getattr_update_times() and nfsd_update_cmtime_attr() call
> notify_change() under inode_lock() but nothing takes freeze protection
> for the export. So they modify filesystems that are frozen. On ext4 that
> trips the WARN_ON() in ext4_journal_check_start().
>
> Reproduced on v7.4-rc1 with two NFSv4.2 clients, the second one in its
> own network namespace:
>
> - client A opens a file O_RDWR and gets a write delegation
> - the export gets frozen
> - client A writes 64k into the file and keeps it open, so the data
> stays in its page cache
> - client B runs stat on the file
>
> nfsd sends CB_GETATTR to client A, sees the file was modified and
> updates the timestamps on the frozen filesystem:
>
> WARNING: fs/ext4/ext4_jbd2.c:90 at ext4_journal_check_start+0x1f6/0x2d0, CPU#0: nfsd/444
> Call Trace:
> __ext4_journal_start_sb+0x7a/0x470
> ext4_dirty_inode+0xa1/0x120
> __mark_inode_dirty+0x154/0x1110
> ext4_setattr+0x2bd/0x24e0
> notify_change+0x81c/0xee0
> nfsd4_deleg_getattr_conflict+0x7f0/0x1370
> nfsd4_encode_fattr4+0x3c3/0x1290
> nfsd4_encode_getattr+0xd1/0x1d0
> nfsd4_encode_operation+0x285/0xf80
> nfsd4_proc_compound+0x5e2/0x23c0
> nfsd_dispatch+0x26d/0x870
> svc_process_common+0xfed/0x19a0
> svc_process+0x600/0xb90
> svc_recv+0x1969/0x2650
> nfsd+0x2f8/0xcd0
>
> The inode's mtime and ctime on the server change while it is frozen.
> That was with delegated timestamps turned off, the
> cb_getattr_update_times() path with them on is the same.
>
> I think nfsd_update_cmtime_attr() has the same problem
> but I haven't reproduced that variant. It runs from:
>
> - nfsd4_copy(), nfsd4_do_async_copy(), nfsd4_clone()
> - nfsd4_finalize_deleg_timestamps() <- nfs4_unlock_deleg_lease() <-
> destroy_unhashed_deleg(), which is reached from DELEGRETURN,
> nfs4_open_delegation(), the laundromat via revoke_delegation(), admin
> revocation, client teardown and nfs4_state_shutdown_net()
>
> mnt_want_write_file() on the delegation's file before inode_lock() would
> do for GETATTR, COPY, CLONE and DELEGRETURN.
>
> But the laundromat and nfs4_state_shutdown_net() shouldn't block on a
> frozen export, I think? Lease expiry for the whole net would stall and
> nfsd shutdown would hang until the thaw. Those probably want
> sb_start_write_trylock() and skip the timestamp update while frozen.
>
> The OPEN with truncate path in nfsd4_truncate() had the same problem.
> I've got a fix for that one in my series.
>
> This goes back to 7e8ae8486e44 ("fs/nfsd: fix update of inode attrs in
> CB_GETATTR") and e5e9b24ab8fa ("nfsd: freeze c/mtime updates with
> outstanding WRITE_ATTRS delegation").
--
Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2026-11-14 11:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 9:35 nfsd: delegated timestamps get written to frozen filesystems Christian Brauner
2026-11-14 11:48 ` Jeff Layton [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=41522fcf40be21bb11409189204bb62ffac47ae4.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=brauner@kernel.org \
--cc=cel@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.