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:	Sun, 24 Apr 2016 14:14:49 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Jan Kara <jack@...e.cz>,
	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

On (04/23/16 21:40), Pavel Machek wrote:
[..]
> > > 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.  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?
> 
> So... from basically linux 0.0, cli() printk("") could be used for
> debugging. ... and that's now gone. Right?
> 
> Can you explain why that is good idea?

it's not gone. you need to explicitly enable async printk mode. the case
you mentioned -- cli() printk("")->console_unlock() -- apart from being
useful in some scenarios, can cause problems in others, simply because
under some circumstances it can run forever, as long as there are printk()
calls coming from other CPUs (which can happen during, f.e., debugging).
did you mean UP systems? well, async printk is sort of useless on UP systems
anyway.

	-ss