On 2023-06-21 20:33:35 [+0900], Tetsuo Handa wrote: > On 2023/06/21 19:40, Sebastian Andrzej Siewior wrote: > > printk_deferred_enter() has to be invoked in non-migrate-able context to > > ensure that deferred printing is enabled and disabled on the same CPU. > > I can't catch. local_irq_save(flags); makes non-migrate-able context > because sleeping is not allowed while IRQ is disabled, doesn't it? That is correct. The problem is the local_irq_save() which remains on PREEMPT_RT and this is problematic during write_seqlock() which acquires spinlock_t which becomes a sleeping lock. write_seqlock_irqsave() substitutes everything properly so on RT there is no local_irq_save(). > > This is the case after zonelist_update_seq has been acquired. > > > > Acquire zonelist_update_seq with write_seqlock_irqsave() and then defer > > printk output. > > What guarantees that write_seqlock_irqsave() never calls printk() > (e.g. lockdep warning) before printk_deferred_enter() takes effect? Actually nothing but this could fixed by making the lockdep annotation first followed by the actual increment in do_write_seqcount_begin_nested(). I don't know this is the other way around since we do annotation followed by locking in order to see the splat before it happens. Let me do a patch for that since it looks like the right thing to do. If this "rare" issue is a blocker I don't see a sane way around it. Be aware that tty_insert_flip_string_and_push_buffer() has atomic/ KASAN annotation which _could_ detect something which then leads to pr_err() invocations while tty_port::lock is acquired. Looking over tty_port_close_start() there are pr_warn() invocation with the lock held so again, possibilities. Petr, is printing via print threads and direct printing via explicit driver callback (which would avoid this problem) on the agenda? Sebastian
