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: <c8e44728-6c09-4fbe-9583-1f8298c3ea39@app.fastmail.com>
Date: Tue, 09 Jul 2024 19:06:25 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jeff Layton" <jlayton@...nel.org>,
 "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, 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

      Arnd