[RFC V1 04/16] perf/events: Replace READ_ONCE() with standard pgtable accessors

[Anshuman Khandual]

On 24/02/26 4:52 PM, Ryan Roberts wrote:
> On 24/02/2026 10:41, Peter Zijlstra wrote:
>> On Tue, Feb 24, 2026 at 10:08:21AM +0000, Mark Rutland wrote:
>>> On Tue, Feb 24, 2026 at 10:41:41AM +0530, Anshuman Khandual wrote:
>>>> Replace READ_ONCE() with standard page table accessors i.e pxdp_get() which
>>>> anyways default into READ_ONCE() in cases where platform do not override.
>>>
>>> For each of the patches where you make this sort of change, please
>>> explain in the commit message *why* it is necessary to do this.
>>>
>>> IIUC the entire point of this is that in subsequent patches, arm64 will
>>> need to use something other than READ_ONCE() for all pXX levels in order
>>> to support D128 translation tables.
>>>
>>> Spelling that out in the commit message makes it much easier for
>>> reviewers to see what's going on, and to focus any discussion/questions,
>>> e.g. *why* won't READ_ONCE() work?
>>
>> That, and only being sent *one* patch, I have no clue what the rest of
>> them are doing. Didn't even get 0/n.
>>
>> I hate people sending me just one patch; just send the whole series
>> already.
> 
> Perhaps Anshuman can forward you the rest of the series, but FWIW, the cover
> letter is here:
> https://lore.kernel.org/all/20260224051153.3150613-1-anshuman.khandual@arm.com/

I have already forwarded the entire series to Peter.

> 
> High level summary is that we are adding support for 128 bit page tables on
> arm64. Existing places that use READ_ONCE() to read PTEs now require 128-bit
> single copy atomicity guarrantees, which READ_ONCE() doesn't allow (on arm64 at
> least) - it fails to compile if used on anything over 64 bit.
> 
> load pair/store pair (ldp/stp) are only single copy atomic if FEAT_LSE128 is
> supported (which is required if FEAT_D128 - 128 bit pgtables - is suported).
> Currently 128 bit pgtables is a compile time decision so we could have chosen to
> extend READ_ONCE()/WRITE_ONCE() to allow 128 bit for this configuration. But
> it's a general purpose API and we were concerned that other users might
> eventually creep in that expect 128 and then fail to compile in the other configs.
> 
> But worse, we are considering eventually making D128 a boot time option, at
> which point we'd have to make READ_ONCE() always allow 128 bit at compile time
> but then it might silently tear at runtime.
> 
> So our preference is to standardize on these existing helpers, which we can
> override in arm64 to give the 128 bit SCA guarrantee when we need it.

That summarizes the intent for this change - will update the commit message
as required. Thanks Ryan for such a detailed explanation.