Re: [PATCH v2 0/6] mm: add basic PTE const type-safety

[Pedro Falcato]

On Wed, Aug 05, 2026 at 04:12:21PM +0530, Anshuman Khandual wrote:
> On Mon, Aug 03, 2026 at 05:43:54PM +0100, Pedro Falcato wrote:
> > Since forever, MM code has thrown pte_t * around with no concern for const
> > safety, or typesafety of any kind. This is confusing. Attempt to address it
> > by:
> > 1) Making sure pte_get*() helpers can cope with const pte_t * arguments
> > 2) Constifying the pte_offset_map_ro_nolock() return type, which by definition
> > already pledges that users will not write to it.
> > 
> > These two simple steps were already able to uncover code smell from
> > khugepaged + do_swap_page().
> > 
> > Separate steps could include introducing pte_offset_map_ro_lock() for more
> > widespread usage of this.
> > 
> > Benefits of this include less confusion and better type-safety. It could also
> > futurely aid in efforts such as [0] which may want semantic annotation of these
> > accesses.
> > 
> > Based on mm-unstable and compile-tested on a handful of architectures.
> > 
> > No functional changes intended.
> 
> Even though the pte accesses should always be type-safe, this series does
> not really address the problem completely and instead changes things only
> for a small set of pte access sites. So just wondering how much beneficial
> this series really is ?

This series is meant to be a small step in the right direction (while
feeling out what the community thinks, which seems to be receptive). The
obvious next steps would be to introduce some sort of

const pte_t *pte_offset_map_ro_lock(struct mm_struct *mm, pmd_t *pmd,
			   unsigned long addr, spinlock_t **ptlp);

and use it in more places. That will obviously involve a bit of churn.


-- 
Pedro