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

[Alexander Gordeev]

On Thu, Aug 27, 2026 at 01:40:01PM +0200, Alexander Gordeev wrote:
> 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.

I did not manage to find any code path that does something like this.

But few archs call ptep_get_lockless() from the hardirq perf handler,
bypassing the per-cpu cache on s390 and (as I read it) violating their
hardware lazy mmu mode. If this is an issue, then it is pre-existing.

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

So leaving local_bh_enable|disable() while adding VM_BUG_ON(in_hardirq())
could actually work.

Also, I do not see how the code could be rearranged to avoid BH disable.