On 12.09.25 16:05, Alexander Gordeev wrote:
On Fri, Sep 12, 2025 at 03:02:15PM +0200, David Hildenbrand wrote:
How would that work with nesting? I feel like there is a fundamental problem
with nesting with what you describe but I might be wrong.
My picture is - flush on each lazy_mmu_disable(), pause on lazy_mmu_pause()
and honour only top-level arch_enter_lazy_mmu_mode_pte(mm, start, end, ptep)
context on all nested levels.
In theory (and if I got it right, you leave the door open for this possibility)
every (mm, start, end, ptep) context could be stored for each nesting level
(as an opaque arch-specific data?).
Yes, I explained that we could do that, for example, by returning a
"struct arch_lazy_mmu_state" from enable() and feeding it into disable().
I would just wish that we could avoid that ...
As an alternative, you could store it somewhere else as an array (percpu
variable? task_struct) and support only a limited number of nesting
levels. The current nesting level could always be retrieved from the
task_struct, for example.
Maybe s390x really wouldn't need support for more than one nesting level
right now.
But I do not really expect it ever, since arch_enter_lazy_mmu_mode_pte()
is only to be called in PTE walkers that never span more than one page
table and follow the pattern:
Well, the cover letter here states:
"Unfortunately, a corner case (DEBUG_PAGEALLOC) may still cause nesting
to occur on arm64. Ryan proposed [2] to address that corner case at the
generic level but this approach received pushback; [3] then attempted to
solve the issue on arm64 only, but it was deemed too fragile."
So I guess we should support nesting cleanly, at least on the core-mm side.
I guess we could start with saying "well, s390x doesn't fully support
nesting yet but doing so just requires changing the way we manage this
per-nesting-level state internally".
s390 is trying to do something different than the other archs here, so
that naturally concerns me :)
But if it's really just about forwarding that data and having s390 store
it somewhere (task_struct, percpu variable, etc), fine with me.
--
Cheers
David / dhildenb
