Hello,
On (06/01/18 14:12), Vaneet Narang wrote:
> > CPU0 CPU1
> >
> > set console verbose
> >
> > dump_backtrace()
> > {
> > // for (;;) print frames
> > printk("%pS\n", frame0);
> > printk("%pS\n", frame1);
> > printk("%pS\n", frame2);
> > printk("%pS\n", frame3);
> > ... console_loglevel = CONSOLE_LOGLEVEL_SILENT;
> > printk("%pS\n", frame12);
> > printk("%pS\n", frame13);
> > }
> >
>
> This is not printk issue, its printk usage issue. User need to handle this
> part using some protection.
>
> What we highlighted is issue related to printk, Where usage is correct
> but still printk can miss some logs due to printk design of asynchronous
> printing.
Yeah, I understand your example from the commit message. What I said was
"the patch does not fully address the problem". One way or another we still
can miss logs due to the very same problem: either console_loglevel
manipulation on another CPU, or printk_safe(), etc. May be there other
scenarios that are broken.
So if we are going to apply the patch [I don't have real objections, and
Petr seems to be fine], then I'd probably ask for a better commit messages.
Namely, I really want to document cases that are not addressed and are
still known to be broken.
-ss
