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
| ||
|
Date: Fri, 2 Sep 2016 17:15:49 +0200 From: Petr Mladek <pmladek@...e.com> To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>, Jan Kara <jack@...e.cz>, Viresh Kumar <viresh.kumar@...aro.org>, Andrew Morton <akpm@...ux-foundation.org>, Jan Kara <jack@...e.com>, Tejun Heo <tj@...nel.org>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Byungchul Park <byungchul.park@....com>, vlevenetz@...sol.com, Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: Re: [PATCH v10 1/2] printk: Make printk() completely async On Fri 2016-09-02 16:58:08, Sergey Senozhatsky wrote: > On (09/01/16 10:58), Petr Mladek wrote: > > On Wed 2016-08-31 21:52:24, Sergey Senozhatsky wrote: > > > a console_unlock() doing > > > wake_up_process(printk_kthread) would make it better. > > > > I am not sure what you mean by this. > > I meant that this thing > > local_irq_save() // or preempt_disable() > ... > if (console_trylock()) > console_unlock(); > ... > local_irq_restore() // or preempt_enable() I see. > can easily lockup the system if console_trylock() was successful and there > are enough messages to print. printk_kthread can't help, because here we > basically enforce the `old' behavior. we have async printk, but not async > console output. tweaking console_unlock() to offload the actual printing loop > to printk_kthread would make the entire console output async: > > static void console_sync_flush_and_unlock(void) > { > for (;;) { > ... > call_console_drivers(); > ... > } > } > > void console_unlock(void) > { > if (!MOTORMOUTH && can_printk_async()) { > up(); > wake_up_process(printk_kthread); > return; > } > console_sync_flush_and_unlock(); > } Something like this would make sense. But I would do it in a separate patch(set). We need to go through all console_unlock() callers and make sure that they are fine with the potential async behavior. I would not complicate the async printk patchset by this. Best Regards, Petr
Powered by blists - more mailing lists