Thread (2 messages) 2 messages, 2 authors, 2023-07-06

Re: [PATCH v2 00/89] fs: new accessors for inode->i_ctime

From: Eric W. Biederman <hidden>
Date: 2023-07-06 17:38:25
Also in: autofs, bpf, ceph-devel, linux-btrfs, linux-cifs, linux-efi, linux-ext4, linux-f2fs-devel, linux-fsdevel, linux-hardening, linux-mm, linux-nfs, linux-rdma, linux-s390, linux-security-module, linux-trace-kernel, linux-unionfs, linux-usb, linux-xfs, lkml, netdev, ntfs3, ocfs2-devel, selinux, v9fs

Possibly related (same subject, not in this thread)

Jeff Layton [off-list ref] writes:
On Wed, 2023-07-05 at 14:58 -0400, Jeff Layton wrote:
quoted
v2:
- prepend patches to add missing ctime updates
- add simple_rename_timestamp helper function
- rename ctime accessor functions as inode_get_ctime/inode_set_ctime_*
- drop individual inode_ctime_set_{sec,nsec} helpers

I've been working on a patchset to change how the inode->i_ctime is
accessed in order to give us conditional, high-res timestamps for the
ctime and mtime. struct timespec64 has unused bits in it that we can use
to implement this. In order to do that however, we need to wrap all
accesses of inode->i_ctime to ensure that bits used as flags are
appropriately handled.

The patchset starts with reposts of some missing ctime updates that I
spotted in the tree. It then adds a new helper function for updating the
timestamp after a successful rename, and new ctime accessor
infrastructure.

The bulk of the patchset is individual conversions of different
subsysteme to use the new infrastructure. Finally, the patchset renames
the i_ctime field to __i_ctime to help ensure that I didn't miss
anything.

This should apply cleanly to linux-next as of this morning.

Most of this conversion was done via 5 different coccinelle scripts, run
in succession, with a large swath of by-hand conversions to clean up the
remainder.
A couple of other things I should note:

If you sent me an Acked-by or Reviewed-by in the previous set, then I
tried to keep it on the patch here, since the respun patches are mostly
just renaming stuff from v1. Let me know if I've missed any.

I've also pushed the pile to my tree as this tag:

    https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/tag/?h=ctime.20230705

In case that's easier to work with.
Are there any preliminary patches showing what you want your introduced
accessors to turn into?  It is hard to judge the sanity of the
introduction of wrappers without seeing what the wrappers are ultimately
going to do.

Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help