Re: [RFC PATCH 1/2] mm: make lazy MMU mode context-aware

[Kevin Brodsky]

On 11/04/2026 11:31, Alexander Gordeev wrote:
> On Tue, Mar 31, 2026 at 04:15:23PM +0200, Kevin Brodsky wrote:
>> On 25/03/2026 17:20, Alexander Gordeev wrote:
>>> On Wed, Mar 25, 2026 at 10:55:23AM +0100, David Hildenbrand (Arm) wrote:
>>>
>>> Hi David,
>>>
>>>>> +/**
>>>>> + * lazy_mmu_mode_enable_pte() - Enable the lazy MMU mode with parameters
>>>> You have to be a lot clearer about implications. For example, what
>>>> happens if we would bail out and not process all ptes? What are the
>>>> exact semantics.
>>> The only implication is "only this address/PTE range could be updated
>>> and that range may span one page table at most".
>>>
>>> Whether all or portion of PTEs were actually updated is not defined,
>>> just like in case of lazy_mmu_mode_enable_pte().
>>>
>>> Makes sense?
>> I also feel that the comment needs to be much more specific. From a
>> brief glance at patch 2, it seems that __ipte_batch_set_pte() assumes
>> that all PTEs processed after this function is called are contiguous.
> No, this is actually not the case. __ipte_batch_set_pte() just sets
> ceilings for later processing. The PTEs within the range could be
> updated in any order and not necessarily all of them.

Fair enough, I suppose what I tried to say is that all PTEs must be in a
certain range :)

>> This should be documented.
> Will do.
>
>>> I will also change arch_enter_lazy_mmu_mode_pte() to
>>> arch_enter_lazy_mmu_mode_for_pte_range() then.
>> Makes sense. The interface looks reasonable to me with this new name.
>>
>> One more comment though: in previous discussions you mentioned the need
>> for arch_{pause,resume} hooks, is that no longer necessary simply
>> because {pause,resume} are not used on the paths where you make use of
>> the new enable function?
> Yes. I did implement arch_pause|resume_lazy_mmu_mode() for a custom
> KASAN sanitizer to catch direct PTE dereferences - ones that bypass
> ptep_get()/set_pte() in lazy mode.

That sounds pretty useful!

> But that code is not upstreamed and therefore there is no need to
> introduce the hooks just right now.

Ack that makes sense.

>> - Kevin
> Thanks for the review, Kevin!

No problem :)

- Kevin