linux-kernel - Re: [PATCH] timekeeping: move multigrain ctime 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: <e4d922c8d0a06de08b91844860c76936bd5fa03a.camel@kernel.org>
Date: Wed, 11 Sep 2024 16:43:02 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Arnd Bergmann <arnd@...nel.org>, John Stultz <jstultz@...gle.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner
 <brauner@...nel.org>, Jan Kara <jack@...e.cz>, Thomas Gleixner
 <tglx@...utronix.de>, Stephen Boyd <sboyd@...nel.org>, 
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, kernel test
 robot <oliver.sang@...el.com>
Subject: Re: [PATCH] timekeeping: move multigrain ctime floor handling into
 timekeeper

On Wed, 2024-09-11 at 20:19 +0000, Arnd Bergmann wrote:
> On Wed, Sep 11, 2024, at 19:55, John Stultz wrote:
> > > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> > > index 5391e4167d60..56b979471c6a 100644
> 
> > My confusion comes from the fact it seems like that would mean you
> > have to do all your timestamping with CLOCK_MONOTONIC (so you have a
> > useful floor value that you're keeping), so I'm not sure I understand
> > the utility of returning CLOCK_REALTIME values. I guess I don't quite
> > see the logic where the floor value is updated here, so I'm guessing.
> 
> I think we could take this further and store the floor value
> in the timekeeper itself rather than in a global variable
> next to the caller.
> 
> And instead of storing the absolute floor value, it would
> be enough to store the delta since the previous
> update_wall_time(), which in turn can get updated by a
> variant of ktime_get_real_ts64() and reset to zero during
> update_wall_time().
>
> timespec64_add_ns() over the traditional version, and the
> fine-grained version needs to atomically update that value.
> If the delta value has to be a 64-bit integer, there also
> needs to be some serialization of the reader side, but I
> think that can be done with read_seqcount_begin() .
> 

I think we'd have to track this delta as an atomic value and cmpxchg
new values into place. The zeroing seems quite tricky to make race-
free.

Currently, we fetch the floor value early in the process and if it
changes before we can swap a new one into place, we just take whatever
the new value is (since it's just as good). Since these are monotonic
values, any new value is still newer than the original one, so its
fine. I'm not sure that still works if we're dealing with a delta that
is siding upward and downward.

Maybe it does though. I'll take a stab at this tomorrow and see how it
looks.

Thanks for the suggestion!
-- 
Jeff Layton <jlayton@...nel.org>