Re: [PATCH v3 0/9] s390: Improve this_cpu operations

From: Yang Shi

Date: Thu May 21 2026 - 19:50:19 EST



On 5/21/26 3:13 PM, David Laight wrote:
On Thu, 21 May 2026 13:46:25 -0700
Yang Shi <yang@xxxxxxxxxxxxxxxxxxxxxx> wrote:

On 5/21/26 10:55 AM, David Laight wrote:
...
The 'trick' here will work for reading/writing values if you don't
care that the value read is stale (or might have been written to
the memory for a different cpu).
If you don't care the stale value, you can just call __this_cpu_read().
You can get an impossible value.
The generated code might be like this:
this_cpu_data = xxx;
preempt_disable_count = this_cpu_data->preempt_disable_count;
If the count was non-zero at the start you'll read the value from
the current cpu and all is fine.
But if the count is zero you can get preempted between the instructions,
the process now running on your 'old' cpu can increment the value
and you then read the new non-zero value.
That won't be good at all.

TBH, I don't think this counts for "don't care the stale value".


You can only use __this_cpu_read() for things that don't change.

The big problem with using per-cpu page tables is there will be absolutely
nothing stopping code taking the wrong address of a per-cpu variable and
saving it somewhere.

Err... I'm lost. If you mean RW or RMW, atomic instructions are required for this_cpu ops. This is how this_cpu ops is implemented for ARM64 even though without percpu page table. If the operation is interrupted in the middle, the exclusion monitor will be cleared, the hardware will reload the value.

If you mean this_cpu_read() some value then this_cpu_write() to the same cpu, I don't think it can work as expected without disabling preemption for the whole code section even though we don't have percpu page table.

Thanks,
Yang

At the moment you have to use the helper so always get the global address.

-- David

Thanks,
Yang