[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <edac512451530bbe4b5f1e8baaeecdcc96e8d39b.camel@kernel.org>
Date: Fri, 14 Nov 2025 14:47:12 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: Christian Brauner <brauner@...nel.org>, Al Viro
<viro@...iv.linux.org.uk>, David Sterba <dsterba@...e.com>, Jan Kara
<jack@...e.cz>, Mike Marshall <hubcap@...ibond.com>, Martin Brandenburg
<martin@...ibond.com>, Carlos Maiolino <cem@...nel.org>, Stefan Roesch
<shr@...com>, linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org,
gfs2@...ts.linux.dev, io-uring@...r.kernel.org, devel@...ts.orangefs.org,
linux-unionfs@...r.kernel.org, linux-mtd@...ts.infradead.org,
linux-xfs@...r.kernel.org, linux-nfs@...r.kernel.org
Subject: Re: re-enable IOCB_NOWAIT writes to files
On Fri, 2025-11-14 at 16:28 +0100, Christoph Hellwig wrote:
> On Fri, Nov 14, 2025 at 09:04:58AM -0500, Jeff Layton wrote:
> > This all looks pretty reasonable to me. There are a few changelog and
> > subject line typos, but the code changes look fine. You can add:
>
> Please tell me about them so I can fix them.
>
> > As far as nfsd's usage of FMODE_NOCMTIME, it looks OK to me. That's
> > implemented today by the check in file_modified_flags(), which is
> > generic and should work across filesystems.
>
> Nothing requires file_update_time / file_modified_flags are helpers
> that a file system may or may not call. I've not done an audit
> if everyone actually uses them.
FWIW, I turned claude loose on this, and it produced:
-------------------------------8<----------------------------------
Findings:
1. coda_file_write_iter (fs/coda/file.c:66-94)
Location: fs/coda/file.c:86Issue: Manually updates ctime in
write_iter operation
inode_set_mtime_to_ts(coda_inode,
inode_set_ctime_current(coda_inode));
Context: This is a stacking filesystem that delegates writes to a
container file via vfs_iter_write(), then manually copies attributes
back. However, it bypasses file_update_time() or file_modified(),
which means it doesn't handle:
- Read-only filesystem checks
- Immutable inode checks
- S_NOCMTIME flag
- i_version updates
- Proper dirty marking
2. efivarfs_file_write (fs/efivarfs/file.c:15-77)
Location: fs/efivarfs/file.c:66Issue: Manually updates ctime in write
operation
inode_set_mtime_to_ts(inode, inode_set_ctime_current(inode));
Context: Uses the legacy .write operation (not .write_iter), but
still a write path that should use proper timestamp helpers.
3. ocfs2_write_end_nolock (fs/ocfs2/aops.c:1926-2050)
Location: fs/ocfs2/aops.c:2024-2026Issue: Manually updates ctime in
write_end callback
inode_set_mtime_to_ts(inode, inode_set_ctime_current(inode));
di->i_mtime = di->i_ctime = cpu_to_le64(inode_get_mtime_sec(inode));
di->i_mtime_nsec = di->i_ctime_nsec =
cpu_to_le32(inode_get_mtime_nsec(inode));
Context: This is called from OCFS2's write path. While
ocfs2_file_write_iter calls __generic_file_write_iter, the write_end
callback manually manages timestamps. This is used both by regular
writes and
page_mkwrite via __ocfs2_page_mkwrite.
4. ubifs_vm_page_mkwrite (fs/ubifs/file.c:1493-1580)
Location: fs/ubifs/file.c:1570Issue: Manually updates ctime in
page_mkwrite operation
inode_set_mtime_to_ts(inode, inode_set_ctime_current(inode));
Context: UBIFS implements its own timestamp update logic with
mctime_update_needed() and manual budgeting for space, bypassing
file_update_time().
-------------------------------8<----------------------------------
Only ocfs2 is exportable, so I think we want to convert that one. The
others I'm not sure of yet.
--
Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists