On Tue, Jun 13, 2023 at 09:09:29AM -0400, Jeff Layton wrote: > On Tue, 2023-05-23 at 14:46 +0200, Jan Kara wrote: > > On Tue 23-05-23 06:40:08, Jeff Layton wrote: > > > On Tue, 2023-05-23 at 12:02 +0200, Jan Kara wrote: > > > > > > > > So there are two things I dislike about this series because I think they > > > > are fragile: > > > > > > > > 1) If we have a filesystem supporting multigrain ts and someone > > > > accidentally directly uses the value of inode->i_ctime, he can get bogus > > > > value (with QUERIED flag). This mistake is very easy to do. So I think we > > > > should rename i_ctime to something like __i_ctime and always use accessor > > > > function for it. > > > > > > > > > > We could do this, but it'll be quite invasive. We'd have to change any > > > place that touches i_ctime (and there are a lot of them), even on > > > filesystems that are not being converted. > > > > Yes, that's why I suggested Coccinelle to deal with this. > > > I've done the work to convert all of the accesses of i_ctime into > accessor functions in the kernel. The current state of it is here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/commit/?h=ctime > > As expected, it touches a lot of code, all over the place. So far I have > most of the conversion in one giant patch, and I need to split it up > (probably per-subsystem). Yeah, you have time since it'll be v6.6 material. > > What's the best way to feed this change into mainline? Should I try to > get subsystem maintainers to pick these up, or are we better off feeding > this in via a separate branch? I would prefer if we send them all through the vfs tree since trickle down conversions are otherwise very painful and potentially very slow.
