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

[David Hildenbrand (Arm)]

On 6/11/26 16:02, Oscar Salvador (SUSE) wrote:
> On Thu, Jun 11, 2026 at 01:50:49PM +0200, David Hildenbrand (Arm) wrote:
>> Let's clean it up a bit:
>>
>> (1) There is no need to pass "full" anymore.
>>
>> (2) No architecture overwrites it, and there isn't really a good reason
>>     to do so when dealing with non-resent PTEs.
>>
>> (3) While at it, call it "non-present", similar to copy_nonpresent_pte()
>>     and zap_nonpresent_ptes().
>>
>> It's a shame that we have clear_non_present_ptes() correspond to
>> pte_clear() and clear_ptes() correspond to ptep_get_and_clear*().
>>
>> Likely we should rename pte_clear() to pte_clear_nonpresent() or sth.
>> like that, to make it clearer that it is usually the wrong interface
>> for dealing with present PTEs.
> 
> Is that always the case, that pte_clear() is only used on non-present
> entries? Or there maybe users that do not care about the current value
> and just want it to nuke?

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.

-- 
Cheers,

David