linux-kernel - Re: 16-bit store instructions &c?

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: <f209bf4d-1d14-404b-8bff-8d6d2854d704@app.fastmail.com>
Date: Thu, 29 Aug 2024 21:56:52 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: linux-kernel@...r.kernel.org, Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: 16-bit store instructions &c?

On Thu, Aug 29, 2024, at 15:37, Paul E. McKenney wrote:
> My plan is to submit a pull request for the remaining three 8-bit
> cmpxchg() emulation commits into the upcoming merge window.  In the
> meantime, I will create similar patches for 16-bit cmpxchg() and perhaps
> also both 8-bit and 16-bit xchg().  I will obviously CC both you and
> Russell on the full set.  And if there are hardware-incompatibility
> complaints, we can deal with them, whether by dropping the offending
> pieces of my patches or by whatever other adjustments make sense.
>
> Does that seem like a reasonable approach, or is there a better way?

There is one thing I'd really like to see happen here, and that is
changing the architectures so they only define the fixed-length
__arch_xchg{8,16,32,64} and __arch_cmpxchg{8,16,32,64} helpers,
ideally as inline functions to have type checking on the pointer.

If we make the xchg()/cmpxchg() functiuons handle all sizes
across architectures, that just ends up cementing the type
agnostic macros, so I feel it would be better to have
fixed-size helpers as the generic API so we can phase out the
use of the existing macros on smaller-than-u32 arguments.

The macro is still needed to allow dealing with both integer
and pointer objects, as well as a mix of 'int' and 'long'
arguments on 64-bit, but for normal fixed-size objects I
think we can best use the same method as the current
xchg64()/cmpxchg64().

    Arnd