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: <c4df5f73-2687-4160-801c-5011193c9046@app.fastmail.com>
Date: Tue, 09 Jul 2024 16:16:37 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Geert Uytterhoeven" <geert@...ux-m68k.org>,
 "Jeff Layton" <jlayton@...nel.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 15:45, Geert Uytterhoeven wrote:
> On Tue, Jul 9, 2024 at 1:58 PM Jeff Layton <jlayton@...nel.org> wrote:
>> I've been getting some of these warning emails from the KTR. I think
>> this is in reference to this patch, which adds a 64-bit try_cmpxchg in
>> the timestamp handling code:
>>
>>     https://lore.kernel.org/linux-fsdevel/20240708-mgtime-v4-0-a0f3c6fb57f3@kernel.org/
>>
>> On m68k, there is a prototype for __invalid_cmpxchg_size, but no actual
>> function, AFAICT. Should that be defined somewhere, or is this a
>> deliberate way to force a build break in this case?
>
> It's a deliberate way to break the build.
>
>> More to the point though: do I need to do anything special for m86k
>> here (or for other arches that can't do a native 64-bit cmpxchg)?
>
> 64-bit cmpxchg() is only guaranteed to exist on 64-bit platforms.
> See also
> https://elixir.bootlin.com/linux/latest/source/include/asm-generic/cmpxchg.h#L62
>
> I think you can use arch_cmpxchg64(), though.

arch_cmpxchg64() is an internal helper provided by some
architectures. Driver code should use cmpxchg64() for
the explicitly 64-bit sized atomic operation.

I'm fairly sure we still don't provide this across all
32-bit architectures though: on architectures that have
64-bit atomics (i686, armv6k, ...) these can be provided
architecture specific code, and on non-SMP kernels they
can use the generic fallback through
generic_cmpxchg64_local(), but on SMP architectures without
native atomics you need a Kconfig dependency to turn off
the particular code.

     Arnd