Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

Hello Jan,

On (03/22/16 07:49), Jan Kara wrote:
> Hi,
> 
> On Tue 22-03-16 02:25:28, Sergey Senozhatsky wrote:
> >  The patch set is based on slightly updated Jan Kara's patches.
> > 
> > This patch set makes printk() completely asynchronous: new messages
> > are getting upended to the kernel printk buffer, but instead of 'direct'
> > printing the actual print job is performed by a dedicated kthread.
> > This has the advantage that printing always happens from a schedulable
> > context and thus we don't lockup any particular CPU or even interrupts.
> > 
> > The patch set is against next-20160321
> > 
> > the series in total has 3 patches:
> > - printk: Make printk() completely async
> > - printk: Make wake_up_klogd_work_func() async
> > - printk: make console_unlock() async
> > 
> > per discussion, "printk: make console_unlock() async" will be posted
> > later on.
> 
> Patches look good to me. I don't think you need to mention the
> console_unlock() async patch when it is not part of the series.

thanks.

> BTW, you seemed to have dropped my patch to skip if there are too
> many buffered messages when oops is in progress. Any reason for that?

I did. seems that my box has some problems with emails delivery recently:
http://marc.info/?l=linux-kernel&m=145821214108806

in short,
I'm afraid we can lose valuable data in some cases.
for example

: hardlockup detector with sysctl_hardlockup_all_cpu_backtrace.
:
: static void watchdog_overflow_callback(...)
: {
:         ...
:         if (is_hardlockup()) {
:         ...
:                 if (sysctl_hardlockup_all_cpu_backtrace &&
:                                !test_and_set_bit(0, &hardlockup_allcpu_dumped))
:                         trigger_allbutself_cpu_backtrace();
:
:                 nmi_panic(regs, msg);
:         ...
:         }
:         ...
: }
:
: trigger_allbutself_cpu_backtrace() can be much more than 100 lines.
: trigger_allbutself_cpu_backtrace() may or may not be implemented via
: NMI. for example arch/sparc/kernel/process_64.c

on a large enough system trigger_allbutself_cpu_backtrace() can easily be more
than 100 lines, and trigger_allbutself_cpu_backtrace() may not be able to print
the backtraces to console (for example this hardlockuped CPU owns the console_sem)
before CPU declares oops_in_progress in nmi_panic()->panic().

	-ss