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: <d6fe52c2-bc9e-424f-a44e-cfc3f4044443@app.fastmail.com>
Date: Wed, 11 Sep 2024 20:19:17 +0000
From: "Arnd Bergmann" <arnd@...nel.org>
To: "John Stultz" <jstultz@...gle.com>, "Jeff Layton" <jlayton@...nel.org>
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, 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().

That way the coarse function only gains a call to
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() .

      Arnd