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

[Peter Zijlstra]

On Tue, Apr 07, 2026 at 08:48:22AM +0200, 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@xxxxxxxxxxxxxxxxxxxx>
> >> Cc: David Hildenbrand <david@xxxxxxxxxx>
> >> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> >> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> >> Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
> >> Cc: Namhyung Kim <namhyung@xxxxxxxxxx>
> >> Cc: linux-perf-users@xxxxxxxxxxxxxxx
> >> Cc: linux-mm@xxxxxxxxx
> >> Cc: linux-kernel@xxxxxxxxxxxxxxx
> >> Acked-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> >> Signed-off-by: Anshuman Khandual <anshuman.khandual@xxxxxxx>
> >> ---
> >> 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@xxxxxxx/
> >>
> >> 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?
> 
> I would assume this to go through the tip tree, but if Peter agrees we
> could route this (mm) patch through the MM tree.

Right, I thought this was part of a larger series and figured it would
ride along with whatever other patches.

If you still want me to pick this up, I can, just state clearly where
this ought to go.