linux-kernel - RE: [PATCH v2 00/10] Introduce cmpxchg128() -- aka. the demise of 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]

Date:   Thu, 2 Feb 2023 22:45:57 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>
CC:     "corbet@....net" <corbet@....net>,
        "will@...nel.org" <will@...nel.org>,
        "boqun.feng@...il.com" <boqun.feng@...il.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "dennis@...nel.org" <dennis@...nel.org>,
        "tj@...nel.org" <tj@...nel.org>, "cl@...ux.com" <cl@...ux.com>,
        "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
        "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
        "agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
        "borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
        "svens@...ux.ibm.com" <svens@...ux.ibm.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
        Arnd Bergmann <arnd@...db.de>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "penberg@...nel.org" <penberg@...nel.org>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        "iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "roman.gushchin@...ux.dev" <roman.gushchin@...ux.dev>,
        "42.hyeyoo@...il.com" <42.hyeyoo@...il.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>
Subject: RE: [PATCH v2 00/10] Introduce cmpxchg128() -- aka. the demise of
 cmpxchg_double()

From: Linus Torvalds
> Sent: 02 February 2023 19:39
> 
> On Thu, Feb 2, 2023 at 7:29 AM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> >  - fixed up the inline asm to use 'u128 *' mem argument so the compiler knows
> >    how wide the modification is.
> >  - reworked the percpu thing to use union based type-punning instead of
> >    _Generic() based casts.
> 
> Looks lovely to me. This removed all my concerns (except for the
> testing one, but all the patches looked nice and clean to me, so
> clearly it must be perfect).

The change is almost certainly for the better.

But did I spot one of the bits using cmpxchg128 just to do an atomic write?
I think it was updating some interrupt info that was at first glance not
dissimilar to that used by MSI-X (it wasn't MSI-X).

If that was a hardware register then it could well require a full bus lock.
Using a write of a sse (or equiv) 128bit register would be an atomic write
without the bus lock problem.

Also, that is only going to work if the hardware/logic side guarantees to
treat a single write as atomic.
I know there are MSI-X implementations out there where the cpu write
will be split into four 32bit writes to some internal memory and the
hardware side will also do multiple accesses.
(Pretty much any implementation on an fpga will behave like that,
not just the one I wrote.)
I didn't see the MSI-X code there, but I do wonder how it safely changes
affinities.

	David

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