Re: [PATCH] perf/events: Replace READ_ONCE() with standard pgtable accessors

[Anshuman Khandual <anshuman.khandual@arm.com>]

On 07/04/26 12:18 PM, David Hildenbrand (Arm) wrote:
> On 4/7/26 05:28, Anshuman Khandual wrote:
>>
>>
>> On 27/02/26 11:57 AM, Anshuman Khandual wrote:
>>> Replace raw READ_ONCE() dereferences of pgtable entries with corresponding
>>> standard page table accessors pxdp_get() in perf_get_pgtable_size(). These
>>> accessors default to READ_ONCE() on platforms that don't override them. So
>>> there is no functional change on such platforms.
>>>
>>> However arm64 platform is being extended to support 128 bit page tables via
>>> a new architecture feature i.e FEAT_D128 in which case READ_ONCE() will not
>>> provide required single copy atomic access for 128 bit page table entries.
>>> Although pxdp_get() accessors can later be overridden on arm64 platform to
>>> extend required single copy atomicity support on 128 bit entries.
>>>
>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>> Cc: David Hildenbrand <david@kernel.org>
>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
>>> Cc: Namhyung Kim <namhyung@kernel.org>
>>> Cc: linux-perf-users@vger.kernel.org
>>> Cc: linux-mm@kvack.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>> ---
>>> This patch applies both on v7.0-rc1 and mm-unstable.
>>>
>>> Part of the D128 series but independent. Hence could be considered on its own.
>>>
>>> https://lore.kernel.org/all/20260224051153.3150613-5-anshuman.khandual@arm.com/
>>>
>>> Collected Peter's tag from an off list conversation.
>>
>> Gentle ping. 
>>
>> Still don't see this patch in latest next-20260406. Hence just
>> wondering which tree and branch this patch is being picked up ?
> 
> It's a trivial change and the last generic code change required for you
> arm64 D128 change, right?

Right.

> 
> I would assume this to go through the tip tree, but if Peter agrees we
> could route this (mm) patch through the MM tree.
> 

Sure