linux-kernel - Re: [GIT PULL] asm-generic fixes for 6.3

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <bc11f501-f020-4e90-9588-5d234e96159d@app.fastmail.com>
Date:   Thu, 06 Apr 2023 22:02:45 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:     Linux-Arch <linux-arch@...r.kernel.org>,
        linux-kernel@...r.kernel.org,
        "Vladimir Oltean" <vladimir.oltean@....com>,
        "Matt Evans" <mev@...osinc.com>
Subject: Re: [GIT PULL] asm-generic fixes for 6.3

On Thu, Apr 6, 2023, at 19:04, Linus Torvalds wrote:
> On Thu, Apr 6, 2023 at 1:13 AM Arnd Bergmann <arnd@...db.de> wrote:
>>
>> Some of the less common I/O accessors are missing __force casts and
>> cause sparse warnings for their implied byteswap, and a recent change
>> to __generic_cmpxchg_local() causes a warning about constant integer
>> truncation.
>
> Ugh. I'm not super-happy about those casts, and maybe sparse should be
> less chatty about these things. It shouldn't be impossible to have
> sparse not warn about losing bits in casts in code that is statically
> dead.
>
> But we seem to have lost our sparse maintainer, so I've pulled this.
>
> I also wish we had a size-specific version of "_Generic()" instead of
> having to play games with "switch (sizeof(..))" like we traditionally
> do.
>
> But things like xchg() and user accesses really just care about the
> size of the object, and there is no size-specific "_Generic()" thing,
> and I can't think of any cute trick either.

There is actually one idea I had a while ago that would (mostly)
solve this:

As far as I can tell, almost no users of
{cmp,}xchg{,_local,_relaxed,acquire,release} that actually use
8-bit and 16-bit objects, and they are not even implemented on
some architectures.

There is already a special case for the 64-bit xchg()/cmpxchg()
variants that can get called on 32-bit architectures, so what
I'd prefer is having each architecture implement only explicit
fixed length cmpxchg8(), cmpxchg16(), cmpgxchg32() and optionally
cmpxchg64() interfaces as normal inline functions that work on
the respective integer types.

The existing interfaces then just need to deal with non-integer
arguments (four byte structures, pointers) that they handle today,
as well as multiplexing between the 32-bit and 64-bit integers
on 64-bit architectures. That still leaves a theoretical sparse
warning when something passes a 64-bit constant, but I don't think
any code does that.

     Arnd