Re: [RFC] metadata updates vs. fetches (was Re: [PATCH v4] fs: Fix data race in inode_set_ctime_to_ts)
From: Matthew Wilcox
Date: Sun Nov 24 2024 - 17:19:41 EST
On Sun, Nov 24, 2024 at 10:10:31PM +0000, Dr. David Alan Gilbert wrote:
> * Al Viro (viro@xxxxxxxxxxxxxxxxxx) wrote:
> > [Linus Cc'd]
> > On Sun, Nov 24, 2024 at 06:56:57PM +0100, Mateusz Guzik wrote:
> >
> > > However, since both sec and nsec are updated separately and there is no
> > > synchro, reading *both* can still result in values from 2 different
> > > updates which is a bug not addressed by any of the above. To my
> > > underestanding of the vfs folk take on it this is considered tolerable.
> >
> > Well... You have a timestamp changing. A reader might get the value
> > before change, the value after change *or* one of those with nanoseconds
> > from another. It's really hard to see the scenario where that would
> > be a problem - theoretically something might get confused seeing something
> > like
> > Jan 14 1995 12:34:49.214 ->
> > Jan 14 1995 12:34:49.137 ->
> > Nov 23 2024 14:09:17.137
> > but... what would that something be?
>
> make?
> i.e. if the change was from:
> a) mmm dd yyyy hh::MM::00:950 ->
> b) mmm dd yyyy hh::MM::01:950 ->
> c) mmm dd yyyy hh::MM::01:200 ->
>
> If you read (b) then you'd think that the file was 750ms newer
> than it really was; which is a long time these days.
... and file fs/inode.c might have a timestamp of :01:717 so inode.o
doesn't get rebuilt when it ought to have been?