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: <b71c161a-8b43-400e-8c61-caac80e685a8@app.fastmail.com>
Date: Thu, 12 Sep 2024 13:17:16 +0000
From: "Arnd Bergmann" <arnd@...nel.org>
To: "Jeff Layton" <jlayton@...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 Thu, Sep 12, 2024, at 11:34, Jeff Layton wrote:
> On Thu, 2024-09-12 at 10:01 +0000, Arnd Bergmann wrote:
>> On Wed, Sep 11, 2024, at 20:43, Jeff Layton wrote:
>>
>> That way you avoid the atomic64_try_cmpxchg()
>> inode_set_ctime_current(), making that case faster,
>> and avoid all overhead in coarse_ctime() unless you
>> use both types during the same tick.
>> 
>
> With the current code we only get a fine grained timestamp iff:
>
> 1/ the timestamps have been queried (a'la I_CTIME_QUERIED)
> 2/ the current coarse-grained or floor time would not show a change in
> the ctime
>
> If we do what you're suggesting above, as soon as one task sets the
> flag, anyone calling current_time() will end up getting a brand new
> fine-grained timestamp, even when the current floor time would have
> been fine.

Right, I forgot about this part of your work, the 
I_CTIME_QUERIED logic definitely has to stay.

> That means a lot more calls into ktime_get_real_ts64(), at least until
> the timer ticks, and would probably mean a lot of extra journal
> transactions, since those timestamps would all be distinct from one
> another and would need to go to disk more often.

I guess some of that overhead would go away if we just treated
tk_xtime() as the floor value without an additional cache,
and did the comparison against inode->i_ctime inside of
a new ktime_get_real_ts64_newer_than(), but there is still the
case of a single inode getting updated a lot, and it would
break the ordering of updates between inodes.

       Arnd