Re: [RFC PATCH 07/13] arm64: percpu: Implement preemptible read/write ops

[Mark Rutland <mark.rutland@arm.com>]

On Tue, Jul 28, 2026 at 10:47:55PM +0100, David Laight wrote:
> On Tue, 28 Jul 2026 13:38:53 +0100
> Mark Rutland <mark.rutland@arm.com> wrote:
> 
> > Use the PCPU GPR infrastructure to implement preemptible this_cpu_read()
> > and this_cpu_write().
> ...
> >  #define this_cpu_write_1(pcp, val)	\
> > -	_pcp_protect(__percpu_write_8, pcp, (unsigned long)val)
> > +	_pcp_wrap(__percpu_write_8, pcp, (unsigned long)val)
> 
> Not new, but does that end up sign extending 'val' which is likely
> to be more expensive than zero extending it?
> Using '(val) + 0u + 0ul' might generate better code in some cases.

For the existing code, there's no {zero,sign}-extension in practice due
to our calling convention (AAPCS64) and inlining. AAPCS64 specifies that
when an N-bit valiue is allocated into a register, bits[N-1:0] contain
the value, and bits[63:N] contain unspecified values.

The existing __percpu_write_##sz() only consumes 'val' as a 'u##sz', so
the compiler doesn't need to do anything with the upper bits (and in
practice doesn't do anything), so long as __percpu_write_##sz() is
inlined into its caller.

The new __percpu_write_##sz() in this series doesn't cast 'val' back
down to a 'u##sz', so there is some unnecessary extension. I'll fix that
by taking 'val' as a 'u##sz' in the function prototype, which'll avoid
extension regardless of inlining.

> Just noticed it should be (unsigned long)(val) as well.
> Otherwise this_cpu_write_n(pcp, -7 / 4) isn't going to DTRT.

Yes, that's a latent bug, and we have at least one other case
(this_cpu_and()) where we miss brackets.

I'll fix those up as a preparatory patches.

Mark.