Messages in this thread | | | Date | Wed, 8 May 2019 17:24:31 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH] RFC: x86/smp: use printk_deferred in native_smp_send_reschedule |
| |
On (05/08/19 10:06), Daniel Vetter wrote: [..] > > Any printk-related patch in this area will make PeterZ really-really > > angry :) > > Hm any more context for someone with no clue about this? Just that the > dependencies are already terribly complex and it's not going to get > better, or something more specific?
The main problem is that it's a deferred error-reporting, so such a report has chances to never be reported. It's not like 'normal' printk() is always guaranteed to immediately start printing; sometimes it will, sometimes it won't, and sometimes it never will, for instance when console_sem was locked by offline-ed CPU.
An example of PeterZ's opinion on printk_deferred() /* message ID: 20181122101606.GP2131@hirez.programming.kicks-ass.net */
| No, printk_deferred() is a disease, it needs to be eradicated, not | spread around.
> > printk_deferred(), just like prinkt_safe(), depends on IRQ work; > > printk_safe(), however, can redirect multiple lines, unlike > > printk_deferred(). So if you want to keep the backtrace, you may > > do something like > > > > if (unlikely(cpu_is_offline(cpu))) { > > printk_safe_enter(...); > > WARN(1, "sched: Unexpected reschedule of offline CPU#%d!\n", > > cpu); > > printk_safe_exit(...); > > return; > > } > > > > I think, in this case John's reworked-printk can do better than > > printk_safe/printk_deferred. > > Hm I think this is what Petr was suggesting, but somehow I didn't find > the printk_safe_* functions and didn't connect the dots.
These are in kernel/printk/printk_safe.c as of now.
> Needs the _irqsave variants I guess, I'll respin a v2 of this.
Let's wait a bit before respin.
-ss
| |