linux-kernel - Re: [jlayton:mgtime 5/13] inode.c:undefined reference to `__invalid_cmpxchg

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: <5c52194a8b449e695a1f22bf525b1fb1674cd2f8.camel@kernel.org>
Date: Tue, 09 Jul 2024 14:27:30 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Arnd Bergmann <arnd@...db.de>, Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org
Subject: Re: [jlayton:mgtime 5/13] inode.c:undefined reference to
 `__invalid_cmpxchg_size'

On Tue, 2024-07-09 at 19:06 +0200, Arnd Bergmann wrote:
> On Tue, Jul 9, 2024, at 17:27, Jeff Layton wrote:
> > On Tue, 2024-07-09 at 17:07 +0200, Arnd Bergmann wrote:
> > > On Tue, Jul 9, 2024, at 16:23, Jeff Layton wrote:
> > 
> > The context for this is generally a write or other change to an
> > inode,
> > so I too am hoping the overhead won't be too bad. It does take
> > great
> > pains to avoid changing the ctime_floor value whenever possible.
> 
> Ok, I see. Have you considered hooking directly into the code
> in kernel/time/timekeeping.c then? 
> 
> Since the coarse time is backed by the timekeeper that itself
> is a cache of the current time, this would potentially avoid
> some duplication:
> 
> - whenever the tk_core code gets updated, you can update
>   the ctime_floor along with it, or integrate ctime_floor
>   itself into the timekeeper
> 
> - you can use the same sequence count logic, either with the
>   same &tk_core.seq or using a separate counter for the
>   ctime updates
> 


Yes, I had considered it on an earlier draft, but my attempt was pretty
laughable. You inspired me to take another look though...

If we go that route, what I think we'd want to do is add a new floor
value to the timekeeper and a couple of new functions:

ktime_get_coarse_floor - fetch the max of current coarse time and floor
ktime_get_fine_floor - fetch a fine-grained time and update the floor

The variety of different offsets inside the existing timekeeper code is
a bit bewildering, but I guess we'd want ktime_get_fine_floor to call
timekeeping_get_ns(&tk->tkr_mono) and keep the latest return cached.
When the coarse time is updated we'd zero out that cached floor value.

Updating that value in ktime_get_fine_floor will require locking or
(more likely) some sort of atomic op. timekeeping_get_ns returns u64
though, so I think we're still stuck needing to do a cmpxchg64.

If there is a way to cut down what we'd need to track to 32-bits or
less though, then that might become more appealing.
-- 
Jeff Layton <jlayton@...nel.org>