Re: [PATCH] mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save().

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2023-06-22 23:28:25 [+0900], Tetsuo Handa wrote:
> On 2023/06/22 23:11, Petr Mladek wrote:
> >> Question to Peter:
> >> Even if local_irq_save(flags) disables IRQ, NMI context can enqueue message via printk().
> >> When does the message enqueued from NMI context gets printed?
> > 
> > They are flushed to the console either by irq_work or by another
> > printk(). The irq_work could not be proceed when IRQs are disabled.
> 
> Is that rule same for both COMFIG_PREEMPT_RT=y and COMFIG_PREEMPT_RT=n ?
> 
> If yes, when Sebastian's patch is applied, IRQs will not be disabled for
> COMFIG_PREEMPT_RT=y kernels because write_seqlock_irqsave() is equivalent
> with write_seqlock() because spin_lock_irqsave(lock, flags) is equivalent
> with spin_lock(lock), and

So why do you accept that spin_lock_irqsave() does not disable
interrupts on PREEMPT_RT but not that printk() is different and has
dedicated printing threads?
Regarding printk:
- dedicated printking thread is used.
- in emergcy cases a different driver is used which does not rely on
  lock held by tty.

> > But another non-deferred printk() would try to flush them immediately.
> > 
> >> If there is a possibility
> >> that the message enqueued from NMI context gets printed between
> >> "write_seqlock_irqsave(&zonelist_update_seq, flags) and printk_deferred_enter()" or
> >> "printk_deferred_exit() and write_sequnlock_irqrestore(&zonelist_update_seq, flags)" ?
> >> If yes, we can't increment zonelist_update_seq.seqcount before printk_deferred_enter()...
> > 
> > It might happen when a printk() is called in these holes.
> 
> printk() can happen between these holes for COMFIG_PREEMPT_RT=y kernels.
> We will need to call printk_deferred_enter() before incrementing
> zonelist_update_seq.seqcount in order to close these holes.

The only hole is the possible lockdep splat which I'm going to change…

Sebastian