linux-kernel - Re: [PATCH v8 01/11] timekeeping: move multigrain timestamp floor handling into timekeeper

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: <4aa41dcb6f4be736355506dd500c4d255e008764.camel@kernel.org>
Date: Tue, 01 Oct 2024 05:45:41 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>, John Stultz <jstultz@...gle.com>, 
 Stephen Boyd <sboyd@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, Steven
 Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Jonathan Corbet
 <corbet@....net>, Chandan Babu R <chandan.babu@...cle.com>, "Darrick J.
 Wong" <djwong@...nel.org>, Theodore Ts'o <tytso@....edu>, Andreas Dilger
 <adilger.kernel@...ger.ca>, Chris Mason <clm@...com>, Josef Bacik
 <josef@...icpanda.com>, David Sterba <dsterba@...e.com>,  Hugh Dickins
 <hughd@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Chuck Lever
 <chuck.lever@...cle.com>, Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org, 
 linux-fsdevel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, 
 linux-doc@...r.kernel.org, linux-xfs@...r.kernel.org,
 linux-ext4@...r.kernel.org,  linux-btrfs@...r.kernel.org,
 linux-nfs@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v8 01/11] timekeeping: move multigrain timestamp floor
 handling into timekeeper

On Mon, 2024-09-30 at 23:35 +0200, Thomas Gleixner wrote:
> On Mon, Sep 30 2024 at 16:53, Jeff Layton wrote:
> > On Mon, 2024-09-30 at 22:19 +0200, Thomas Gleixner wrote:
> > > On Mon, Sep 30 2024 at 15:37, Jeff Layton wrote:
> > > > If however, two threads have racing syscalls that overlap in time, then there                       
> > > > is no such guarantee, and the second file may appear to have been modified                          
> > > > before, after or at the same time as the first, regardless of which one was                         
> > > > submitted first.
> > > 
> > > That makes me ask a question. Are the timestamps always taken in thread
> > > (syscall) context or can they be taken in other contexts (worker,
> > > [soft]interrupt, etc.) too?
> > > 
> > 
> > That's a good question.
> > 
> > The main place we do this is inode_set_ctime_current(). That is mostly
> > called in the context of a syscall or similar sort of operation
> > (io_uring, nfsd RPC request, etc.).
> > 
> > I certainly wouldn't rule out a workqueue job calling that function,
> > but this is something we do while dirtying an inode, and that's not
> > typically done in interrupt context.
> 
> The reason I'm asking is that if it's always syscall context,
> i.e. write() or io_uring()/RPC request etc., then you can avoid the
> whole global floor value dance and make it strictly per thread, which
> simplifies the exercise significantly.
> 

I'm not sure I follow what you're proposing here.

Consider two threads doing writes serially to different files. IOW, the
second thread enters the write() syscall after the first thread returns
from its write(). In that situation, the second timestamp mustn't
appear to be earlier than the first (assuming no backward clock jump,
of course).

How would we ensure that with only per-thread structures?

> But even if it's not syscall/thread context then the worker or io_uring
> state machine might just require to serialize against itself and not
> coordinate with something else. But what do I know.

-- 
Jeff Layton <jlayton@...nel.org>