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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Mar 2016 16:57:38 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jan Kara <jack@...e.com>, Petr Mladek <pmladek@...e.com>,
	Tejun Heo <tj@...nel.org>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	linux-kernel@...r.kernel.org,
	Byungchul Park <byungchul.park@....com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async

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