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 07:49:48 +0100
From:	Jan Kara <jack@...e.cz>
To:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:	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

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.  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?

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR