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
