On Mon 2022-07-25 12:04:50, John Ogness wrote: > On 2022-07-25, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > I remember asking why it is needed to disable interrupts across > > vsnprintf(). John, can I take this as-it or are you sending a new > > batch? > > Mike's patch only addresses the vsnprintf() to print the prefix and get > the message length. There is also a vscnprintf() for the message itself, > which is still happening with interrupts disabled (see > printk_sprint()). I suppose this patch side-steps the splat because the > first vsnprintf() already triggered the random bytes for the pointer > hash. > > I am preparing a new series that addresses this by completely removing > interrupt disabling from the printk() path. This required changes to the > printk_enter() macro, recursion handling, and the printk-ringbuffer > itself. > > The focus of my new series are the various non-RT issues reported during > the early 5.19-rc cycles. I still need more time to get the series into > shape for LKML. The pull request for-5.20 was a great fiasko, see https://lore.kernel.org/r/CAHk-=wie+VC-R5=Hm=Vrg5PLrJxb1XiV67Efx-9Cr1fBKCWHTQ@xxxxxxxxxxxxxx We need to be super careful with the next pull request if there will be any. My proposal is to start with as conservative version of printk kthread(s) as possible. It means to start either with a single kthread. Or use per-console kthreads where the critical section will be guarded by per-console. The single kthread will help to avoid any races that were originally prevented by console_sem(). The spin lock will cause that printk kthreads will never block the global console_lock while sleeping (at least on non-RT system). I am not going to accept any removal of disabled interrupts in the first round. It opens another can of worms. I understand that enabled interrupts will be needed on RT kernel. We could do it later when the conservative kthread(s) are accepted. And we could do it RT-specific. But we have to keep consoles as reliable as possible in non-RT system. Best Regards, Petr
