Re: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values

[Muhammad Usama Anjum <usama.anjum@xxxxxxx>]

On 11/09/2026 5:55 pm, David Hildenbrand (Arm) wrote:
> On 9/3/26 12:29, Muhammad Usama Anjum wrote:
>> Hi,
>>
>> pte_t currently describes both a software PTE value and an element stored
>> in a PTE table. Consequently, pte_t * can point either to a software PTE
>> value, often a stack copy, or to a PTE-table slot. The compiler cannot
>> distinguish these cases. A value pointer can therefore be passed to an
>> interface that expects table storage, while table storage can be read by
>> direct dereference instead of the architecture accessor.
>>
>> This series begins a staged conversion at the PTE level. It introduces
>> hw_pte_t as the element type for PTE-table storage and converts generic
>> MM to use hw_pte_t *. Software PTE values remain pte_t. Interfaces that
>> intentionally return a value through pte_t *, such as install_pte,
>> remain value interfaces; the relevant parameters are named ptentp to
>> make that distinction explicit.
>>
>> The generic definition aliases hw_pte_t to pte_t unless an architecture
>> selects ARCH_HAS_HW_PTE_T, which enables a distinct generic wrapper named
>> __hw_pte_t. Some architectures define pgtable_t in headers parsed before
>> the generic hw_pte_t typedef is visible. The structure tag allows those
>> headers to define pgtable_t as struct __hw_pte_t * without creating an
>> include-order dependency. This is required when converting s390, m68k,
>> powerpc and sparc.
>>
>> No architecture selects ARCH_HAS_HW_PTE_T in this series, so the
>> representation and behavior of every architecture are preserved. ptep_get()
>> keeps its existing READ_ONCE() semantics and converts the stored element
>> through __pte_from_hw(). An architecture can later select the option and
>> convert its PTE interfaces to make the distinction compiler-enforced.
>> Architecture PTE implementations and most architecture code are
>> deliberately left for those later opt-in conversions.
>>
>> Here, hw_pte_t identifies PTE-table storage rather than table lifetime:
>> complete PTE tables use hw_pte_t whether or not they are currently
>> linked into a page-table hierarchy, while software PTE values use
>> pte_t. The distinction between complete but unlinked tables and
>> hardware-reachable tables was raised during discussion and remains an
>> important point for review.
>>
>> PMD, PUD, P4D and PGD storage are deliberately out of scope. They can be
>> converted in later series after the PTE boundary is agreed, avoiding the
>> PMD-specific cases that made an all-level conversion difficult to
>> review.
>>
>> Most mechanical pointer conversions were generated with the Coccinelle
>> script included below, then audited and fixed by hand.
>>
>> This series does not add a second ptep_get_once() accessor and does not
>> remove or replace STRICT_MM_TYPECHECKS.
>>
>> The design discussion is available at [1]; while the original idea came
>> from [2].
>>
>> I've the patches here [3] for arm64 conversion which I used to find
>> usages in generic code which I missed during development. These would be
>> sent separately.
> 
> Unless there is more feedback on the overall approach, the next step for this 
> is
> to have at least one architecture support posted.
> 
> We should only merge this if at least one architecture (better two? :) arm64 
> and
> s390x? ) would merge the architecture bits.
> 
> That is, we should get an ACK from the arch maintainer son the common code 
> bits
> and the arch bits.
> 

Thank you for reviewing the series. I've posted the patches for arm64 just
now [1]. Let's wait for arm64 maintainers to ACK the patches.

[1] https://lore.kernel.org/all/20260914-pte0_arm-v1-0-bb53b663e396@xxxxxxx 

-- 
Thanks,
Usama