Re: [RFC V1 09/16] arm64/mm: Route all pgtable reads via ptdesc_get()

["David Hildenbrand (Arm)" <david@kernel.org>]

On 3/2/26 05:34, Anshuman Khandual wrote:
> 
> 
> On 28/02/26 4:47 PM, Mike Rapoport wrote:
>> Hi Anshuman,
>>
>> On Tue, Feb 24, 2026 at 10:41:46AM +0530, Anshuman Khandual wrote:
>>> Define arm64 platform specific implementations for new pXdp_get() helpers.
>>> These resolve into READ_ONCE(), thus ensuring required single copy atomic
>>> semantics for the page table entry reads.
>>>
>>> In future this infrastructure can be used for D128 to maintain single copy
>>> atomicity semantics with inline asm blocks.
>>>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Will Deacon <will@kernel.org>
>>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>> ---
>>>  arch/arm64/include/asm/pgtable.h | 28 +++++++++++++++++++++++++++-
>>>  1 file changed, 27 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>> index 257af1c3015d..804ef49aea88 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -84,6 +84,32 @@ static inline void arch_leave_lazy_mmu_mode(void)
>>>  	arch_flush_lazy_mmu_mode();
>>>  }
>>>  
>>> +#define ptdesc_get(x)		READ_ONCE(x)
>>
>> This will be confusing with 'struct ptdesc' APIs, maybe ptent_get()?
> 
> Created 'ptdesc_t' earlier on arm64 platform as an unified data type, which could
> represent page table entries including their protection fields and masks for any
> level.
> 
> typedef u64 ptdesc_t;
> 
> typedef ptdesc_t pteval_t;
> typedef ptdesc_t pmdval_t;
> typedef ptdesc_t pudval_t;
> typedef ptdesc_t p4dval_t;
> typedef ptdesc_t pgdval_t;
> 
> But now it conflicts with generic 'struct ptdesc'. Agreed that overall renaming is
> required. Probably ptent_t along with ptent_get/set() could be an option. But that
> is probably orthogonal to the series and can be done later in a separate patch.

We often refer to *ptep as ptent. Can we find something that does not
contain "pte" to avoid confusion with pteval_t ?

We often refer to the set of functions as "pXX" or "pxx". pxxval_t would
certainly be an option, but it would be the first "official" such
occurrence.

-- 
Cheers,

David