Re: [PATCH v7 2/4] s390/mm: Batch PTE updates in lazy MMU mode

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

On Thu, Aug 27, 2026 at 10:11:56AM +0200, Heiko Carstens wrote:
> On Wed, Aug 26, 2026 at 04:34:25PM +0200, Alexander Gordeev wrote:
> > On Wed, Aug 26, 2026 at 03:02:57PM +0200, Heiko Carstens wrote:
> > > Would be nice if we could avoid the not so obvious local_bh_disable()
> > > and local_bh_enable() pairs.
> > 
> > Calling ptep_get() from BH context was certainly unexpected, but the way
> > local_bh_enable|disable() pairs are used is actually straightforward.
> > This is a slow path anyway, so I would think the simplicity prevails in
> > this case.
> > 
> > But again, I will try to avoid that.
> 
> I do agree that ptep_get() being called from BH context is not what I
> would have expected too. But then again, nothing prevents people from
> doing that from irq context too, no matter if that is sane or not.

I am currently looking if any interrupt handler does such a crazy thing.
If not, I hope it would be possible to nail this requirement with the
maintainers and e.g. add VM_BUG_ON(in_hardirq()) to ptep_get()/set_pte()
implementations.

But even with BHs we have an interesting situation: calling ptep_get()
from a BH while in the lazy MMU mode is actually a read hazard. IOW what
I hit looks to me as a bug in generic code, and one that looks very
difficult to fix. So staying with local_bh_enable|disable() would be
still a good tradeoff.

> Imho the "final" version should either be implemented that it can go
> without disabling bottom halves, or, if that is not worth the effort,
> even disable interrupts, just to avoid other surprises.

Yes, that would be the last resort.

> Plus a comment why it is needed, please.

Sure.