linux-kernel - [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: <20241124215014.GA3387508@ZenIV>
Date: Sun, 24 Nov 2024 21:50:14 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: "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: [RFC] metadata updates vs. fetches (was Re: [PATCH v4] fs: Fix data
 race in inode_set_ctime_to_ts)

[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?

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.