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: <b300fec8b6f611662195e0339f290d473a41607c.camel@kernel.org>
Date: Mon, 16 Sep 2024 06:57:40 -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-16 at 12:32 +0200, Thomas Gleixner wrote:
> On Mon, Sep 16 2024 at 12:12, Thomas Gleixner wrote:
> > On Sat, Sep 14 2024 at 13:07, Jeff Layton wrote:
> > > +	do {
> > > +		seq = read_seqcount_begin(&tk_core.seq);
> > > +
> > > +		ts->tv_sec = tk->xtime_sec;
> > > +		mono = tk->tkr_mono.base;
> > > +		nsecs = timekeeping_get_ns(&tk->tkr_mono);
> > > +		offset = *offsets[TK_OFFS_REAL];
> > > +	} while (read_seqcount_retry(&tk_core.seq, seq));
> > > +
> > > +	mono = ktime_add_ns(mono, nsecs);
> > > +
> > > +	if (atomic64_try_cmpxchg(&mg_floor, &old, mono)) {
> > > +		ts->tv_nsec = 0;
> > > +		timespec64_add_ns(ts, nsecs);
> > > +	} else {
> > > +		/*
> > > +		 * Something has changed mg_floor since "old" was
> > > +		 * fetched. "old" has now been updated with the
> > > +		 * current value of mg_floor, so use that to return
> > > +		 * the current coarse floor value.
> > 
> > 'Something has changed' is a truly understandable technical
> > explanation.
> 
>      old = mg_floor
>                                 mono = T1;
>                                 mg_floor = mono
> preemption
> 
>      do {
>         mono = T2;
>      }
> 
>      cmpxchg fails and the function returns a value based on T1
> 
> No?
> 
> 

Packing for LPC, so I can't respond to all of these just now, but I
will later. You're correct, but either outcome is OK.

The requirement is that we don't hand out any values that were below
the floor at the time that the task entered the kernel. Since the time
changed while the task was already inside the kernel, either T1 or T2
would be valid timestamps.
-- 
Jeff Layton <jlayton@...nel.org>