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: Tue, 12 Mar 2019 13:38:57 +0100 From: Petr Mladek <pmladek@...e.com> To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> Cc: John Ogness <john.ogness@...utronix.de>, linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>, Steven Rostedt <rostedt@...dmis.org>, Daniel Wang <wonderfly@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Alan Cox <gnomes@...rguk.ukuu.org.uk>, Jiri Slaby <jslaby@...e.com>, Peter Feiner <pfeiner@...gle.com>, linux-serial@...r.kernel.org, Sergey Senozhatsky <sergey.senozhatsky@...il.com> Subject: Re: [RFC PATCH v1 00/25] printk: new implementation On Mon 2019-03-11 19:54:11, Sergey Senozhatsky wrote: > On (03/07/19 10:53), John Ogness wrote: > > Since all current console drivers are already irq safe, I'm > > wondering if using irq_work to handle the emergency printing for console > > drivers without write_atomic() would help. (If the printk caller is in a > > context that write() supports, then write() could be called directly.) > > This would also demand that the irq-safe requirements for write() are > > not relaxed. The printk-kthread might still be faster than irq_work, but > > it might increase reliability if an irq_work is triggered as an extra > > precaution. > > Hmm. OK. So one of the things with printk is that it's fully sequential. > We call console drivers one by one. Slow consoles can affect what appears > on the fast consoles; fast console have no impact on slow ones. > > call_console_drivers() > for_each_console(c) > c->write(c, text, text_len); > > So a list of (slow_serial serial netcon) console drivers is a camel train; > fast netcon is not fast anymore, and slow consoles sometimes are the reason > we have dropped messages. And if we drop messages we drop them for all > consoles, including fast netcon. Turning that sequential pipline into a > bunch of per-console kthreads/irq and letting fast consoles to be fast is > not a completely bad thing. Let's think more about this, I'd like to read > more opinions. Per-console kthread sounds interesting but there is the problem with reliability. I mean that kthread need not get scheduled. Some of these problems might get solved by the per-console loglevel patchset. Sigh, any feature might be useful in some situation. But we always have to consider the cost and the gain. I wonder how common is to actively use two consoles at the same time and what would be the motivation. Best Regards, Petr
Powered by blists - more mailing lists