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: <92726965-19a0-433b-9b49-69af84b25081@app.fastmail.com>
Date: Tue, 09 Jul 2024 17:07:58 +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 16:23, Jeff Layton wrote:
> On Tue, 2024-07-09 at 16:16 +0200, Arnd Bergmann wrote:
>> On Tue, Jul 9, 2024, at 15:45, Geert Uytterhoeven wrote:
>
> I think the simplest solution is to make the floor value I'm tracking
> be an atomic64_t. That looks like it should smooth over the differences
> between arches. I'm testing a patch to do that now.

Yes, atomic64_t should work, but be careful about using this
in a fast path since it can turn into a global spinlock
in lib/atomic64.c on architectures that don't support it
natively.

I'm still reading through the rest of your series, but
it appears that you pass the time value into 
ktime_to_timespec64() directly afterwards, so I guess
that is already a fairly large overhead on 32-bit
architectures and an extra spinlock doesn't hurt too
much.

Two more things I noticed in your patch:

- smp_load_acquire() on a 64-bit variable seems problematic
  as well, maybe this needs a spinlock on 32-bit
  architectures?

- for the coarse_ctime function, I think you should be
  able to avoid the conversion to timespec by just calling
  ktime_get_coarse_real_ts64() again instead of converting
  monotonic to real and then to timespec.

- inode_set_ctime_current() seems to now store a fine-grained
  timespec in the inode even for the !is_mgtime case, skipping
  the timestamp_truncate() step. This appears to potentially
  leak a non-truncated value to userspace, which would be
  inconsistent with the value read back from disk.

      Arnd