linux-kernel - RE: [PATCH 2/2] locking/lockref/x86: Enable ARCH_USE_CMPXCHG_LOCKREF for X86_32 && X86

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: <48001b3d732b418eb5f36def228c2c9d@AcuMS.aculab.com>
Date:   Thu, 26 May 2022 08:30:26 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Uros Bizjak <ubizjak@...il.com>
CC:     the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Waiman.Long@...com" <Waiman.Long@...com>,
        Paul McKenney <paulmck@...ux.vnet.ibm.com>
Subject: RE: [PATCH 2/2] locking/lockref/x86: Enable ARCH_USE_CMPXCHG_LOCKREF
 for X86_32 && X86_CMPXCHG64

From: Linus Torvalds
> Sent: 25 May 2022 17:30
> 
> On Wed, May 25, 2022 at 7:40 AM Uros Bizjak <ubizjak@...il.com> wrote:
> >
> > +       select ARCH_USE_CMPXCHG_LOCKREF if X86_64 || (X86_32 && X86_CMPXCHG64)
> 
> Ugh. That looks pointlessly complicated. X86_64 already enables
> X86_CMPXCHG64 afaik, so you can just say
> 
>         select ARCH_USE_CMPXCHG_LOCKREF if X86_CMPXCHG64
> 
> which is much clearer: CMPXCHG_LOCKREF needs CMPXCHG64, and the
> Kconfig option says exactly that.
> 
> That said, this also makes me wonder if we should just make cmpxchg8b
> requirement unconditional.
> 
> Googling around, it looks like Windows NT stopped booting on CPUs
> without cmpxchg8b in version 5.1. That was in 2001.
> 
> Here we are, 21 years later, and we still ostensibly try to support
> CPUs without it, but I doubt it's worth it.
> 
> So maybe time to just say "we require cmpxchg8b".
> 
> In fact, I think we have effectively done that already for years, since we have
> 
>     config X86_CMPXCHG64
>             def_bool y
>             depends on X86_PAE || ...
> 
> iow, enabling X86_PAE will force-enable CMPXCHG8B due to the wider
> page table entries.
> 
> And I would assume that all distros basically do that anyway (but I do
> not have a 32-bit distro around to check).
> 
> It would mean that we would finally drop support for i486 (and
> possibly some Pentium clones, but afaik a number of them did actually
> support cmpxchg8b even if they didn't report it in cpuid).

Perhaps there could be a non-smp implementation of cmpxchg8b
that just disables interrupts?

While I have used a dual 486 I doubt Linux would run ever
have on it. The same is probably true for old dual Pentiums.

I think there are still some 486-class embedded cpu that include
a few of the newer instructions (usually things like rdtsc).
But they won't be smp.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)