Re: [PATCH 3/3] mm: cleanup clear_not_present_full_ptes() and rename to clear_non_present_ptes()

[Oscar Salvador (SUSE)]

On Thu, Jun 11, 2026 at 06:14:34PM +0200, David Hildenbrand (Arm) wrote:
> Usually, you want to get access and dirty bits, and that requires get_and_clear
> semantics. I suspect there are some more details to the low-level helpers.
> 
> > 
> > I guess that such a renaming would have to first audit that all current
> > users obey that? Othen than that, is there anything else stopping us
> > from doing so?
> 
> When I last skimmed over some users, they were all dealing with non-present
> entries. (mremap.c, rmap.c, mpreotect.c, memory.c, madvise.c)
> 
> But yes, we would have to audit and make sure that's the case.

So, I quickly checked some users.

As you mentioned, users from rmap.c, mremap.c, memory.c and madvise.c
deal with non-present ptes.
Hugetlb via huge_pte_clear does it for uffd markers or explicit !pte_present, so
that is fine as well.
That is wrt. generic code.

Now, moving to arch-specific code, things look a bit funny.

E.g: bpf:

arena_free_pages()-> apply_range_clear_cb()

apply_range_clear_cb() only calls pte_clear for present ptes.

Then, e.g: remove_pagetable() from powerpc and and x86 end up calling pte_clear
(for present ptes), but that is fine because we are just nuking it.
And s390 has the same in modify_pte_table()



-- 
Oscar Salvador
SUSE Labs