On Mon 2021-03-22 22:58:47, John Ogness wrote: > On 2021-03-22, Petr Mladek <pmladek@xxxxxxxx> wrote: > > On Mon 2021-03-22 12:16:15, John Ogness wrote: > >> On 2021-03-21, Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> wrote: > >> >> @@ -369,7 +70,10 @@ __printf(1, 0) int vprintk_func(const char *fmt, va_list args) > >> >> * Use the main logbuf even in NMI. But avoid calling console > >> >> * drivers that might have their own locks. > >> >> */ > >> >> - if ((this_cpu_read(printk_context) & PRINTK_NMI_DIRECT_CONTEXT_MASK)) { > >> >> + if (this_cpu_read(printk_context) & > >> >> + (PRINTK_NMI_DIRECT_CONTEXT_MASK | > >> >> + PRINTK_NMI_CONTEXT_MASK | > >> >> + PRINTK_SAFE_CONTEXT_MASK)) { > >> > > >> But I suppose I could switch > >> the 1 printk_nmi_direct_enter() user to printk_nmi_enter() so that > >> PRINTK_NMI_DIRECT_CONTEXT_MASK can be removed now. I would do this in a > >> 4th patch of the series. > > > > Yes, please unify the PRINTK_NMI_CONTEXT. One is enough. > > Agreed. (But I'll go even further. See below.) > > > I wonder if it would make sense to go even further at this stage. > > What is possible? > > > > 1. We could get rid of printk_nmi_enter()/exit() and > > PRINTK_NMI_CONTEXT completely already now. It is enough > > to check in_nmi() in printk_func(). > > > > Agreed. in_nmi() within vprintk_emit() is enough to detect if the > console code should be skipped: > > if (!in_sched && !in_nmi()) { > ... > } Well, we also need to make sure that the irq work is scheduled to call console later. We should keep this dicision in printk_func(). I mean to replace the current if (this_cpu_read(printk_context) & (PRINTK_NMI_DIRECT_CONTEXT_MASK | PRINTK_NMI_CONTEXT_MASK | PRINTK_SAFE_CONTEXT_MASK)) { with /* * Avoid calling console drivers in recursive printk() * and in NMI context. */ if (this_cpu_read(printk_context) || in_nmi() { That said, I am not sure how this fits your further rework. I do not want to complicate it too much. I am just afraid that the discussion about console rework might take some time. And this would remove some complexity before we started the more complicated or controversial changes. > > 2. I thought about unifying printk_safe_enter()/exit() and > > printk_enter()/exit(). They both count recursion with > > IRQs disabled, have similar name. But they are used > > different way. > > > > But better might be to rename printk_safe_enter()/exit() to > > console_enter()/exit() or to printk_deferred_enter()/exit(). > > It would make more clear what it does now. And it might help > > to better distinguish it from the new printk_enter()/exit(). > > > > I am not sure if it is worth it. > > I am also not sure if it is worth the extra "noise" just to give the > function a more appropriate name. The plan is to remove it completely > soon anyway. My vote is to leave the name as it is. OK, let's keep printk_safe() name. It was just an idea. I wrote it primary to sort my thoughts. Best Regards, Petr _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec