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

[Alexander Gordeev <agordeev@linux.ibm.com>]

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.

> 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.

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

> - Kevin

Thanks for the review, Kevin!