[lkml]   [2019]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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: */

| 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.


 \ /
  Last update: 2019-05-08 10:25    [W:0.071 / U:3.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site