Re: [RFC PATCH 0/4] mm: introduce __ptent sparse attribute

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

On 7/17/26 14:32, Alexander Gordeev wrote:
> Hi All!
> 
> This RFC is a result the implementation of lazy MMU mode on s390 [1].
> 
> Heiko Carstens requested some mechanism that would rule out direct
> dereferencing of PTE pointers, which otherwise would bypass the per-
> cpu cache on s390 and lead to catastrophic results.
> 
> This is an attempt to introduce __ptent sparse attribute similar to
> __private, but to be applied only to pte_t type by architectures.
> When used with C=1 the modified sparse "dereference of PTE pointer"
> warning is emitted.
> 
> With using that new mechanism I was able to identify direct PTE
> pointer dereferences, which should not have existed after commit
> c33c794828f2 ("mm: ptep_get() conversion") (and its follow-ups).
> 
> In addition to ptep_get() and set_pte() accessors I suggest to
> introduce ptep_get_nopgtable() and set_pte_nopgtable() variants
> to use when a PTE pointer does not point to the page table, but
> rather to a copy of the PTE. These would allow dropping unnecessary
> checks on s390, but is already the case for folio_pte_batch_flags().
> 
> Patches 1,2 are independent from the sparse rework and are good to go AFAICT.
> Patch 3 is the required change to be coupled with the sparse rework below.
> Patch 4 is an example of how __ptent was implemented on s390.
> 
> I hesitate to post the sparse patch itself before the rework is is agreed,
> but I am CC-ing the sparse mailing list.

Usama is working on something bigger, whereby we introduce the concept of pte_t
and hw_pte_t in common code, and allow to decouple them on architectures that
really need (IOW that implement it in their arch code).

On architecture that decouple both types, the compiler will do the type checking
for us.

The prototype patches I saw looked pretty encouraging (at least for pte_t, pmd_t
is more involved).

There is some information here:

https://lore.kernel.org/r/6110202c-057b-4701-8c04-1a76ee7bb9ab@arm.com

And I'm sure Usama can share some more details with you to give you a better
idea if that would solve the problem for s390x as well.

-- 
Cheers,

David