linux-kernel - Re: [RFC] metadata updates vs. fetches (was Re: [PATCH v4] fs: Fix data race in inode_set_ctime_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z0OkVxY3CW9fV8tp@gallifrey>
Date: Sun, 24 Nov 2024 22:10:31 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Mateusz Guzik <mjguzik@...il.com>,
	"Darrick J. Wong" <djwong@...nel.org>,
	Hao-ran Zheng <zhenghaoran@...a.edu.cn>, brauner@...nel.org,
	jack@...e.cz, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, baijiaju1990@...il.com,
	21371365@...a.edu.cn,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] metadata updates vs. fetches (was Re: [PATCH v4] fs: Fix
 data race in inode_set_ctime_to_ts)

* Al Viro (viro@...iv.linux.org.uk) 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.

Dave

> We could add a seqcount, but stat(2) and friends already cost more than
> they should, IMO...
> 
> Linus, do you see any good reasons to bother with that kind of stuff?
> It's not the first time such metadata update vs. read atomicity comes
> up, maybe we ought to settle that for good and document the decision
> and reasons for it.
> 
> This time it's about timestamp (seconds vs. nanoseconds), but there'd
> been mode vs. uid vs. gid mentioned in earlier threads.
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/