Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async
From: Sergey Senozhatsky
Date: Tue Mar 22 2016 - 03:56:30 EST
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