On Thu, Apr 6, 2023, at 19:04, Linus Torvalds wrote:
> On Thu, Apr 6, 2023 at 1:13 AM Arnd Bergmann <arnd@xxxxxxxx> 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
