[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiM5CNFsxnTnKxX+bGgA8E5r=sSD5iy2evcTDs0ARihHw@mail.gmail.com>
Date: Sun, 23 Jun 2024 13:42:37 -0400
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Uros Bizjak <ubizjak@...il.com>
Cc: kernel test robot <lkp@...el.com>, oe-kbuild-all@...ts.linux.dev,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Borislav Petkov <bp@...en8.de>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: arch/x86/include/asm/cmpxchg_32.h:149:9: error: inline assembly
requires more registers than available
On Sun, 23 Jun 2024 at 11:42, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> For example, why does that 32-bit __arch_try_cmpxchg64() do this:
>
> if (unlikely(!ret)) \
> *(_oldp) = o.full; \
>
> when I think it would be simpler and more straightforward to just do
> that *(_oldp) = o.full unconditionally?
I can repro the clang issue, and no, removing the conditional doesn't fix it.
A plain revert of
95ece48165c1 ("locking/atomic/x86: Rewrite x86_32
arch_atomic64_{,fetch}_{and,or,xor}() functions")
does fix it.
The problem does *NOT* happen with a defconfig, so it's clearly
triggered by some horror in that config:
https://download.01.org/0day-ci/archive/20240623/202406230912.F6XFIyA6-lkp@intel.com/config
and a quick config bisection seems to imply that it might just be
X86_MINIMUM_CPU_FAMILY 6 -> 4
from setting CONFIG_MGEODEGX1=y instead of M686.
Hmm. While I'm not willing to leave x86-32 behind, I personally have
thought for a couple of years that we should leave Pentium and earlier
behind. We should just require cmpxchg64b support.
It does look like the complication at least partly comes from the
emulation alternative, but I didn't go look any closer.
Linus
Powered by blists - more mailing lists