mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>

      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 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 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®