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, 31 Mar 2017 16:56:02 +0200 From: Petr Mladek <pmladek@...e.com> To: Sergey Senozhatsky <sergey.senozhatsky@...il.com> Cc: Steven Rostedt <rostedt@...dmis.org>, Jan Kara <jack@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Peter Zijlstra <peterz@...radead.org>, "Rafael J . Wysocki" <rjw@...ysocki.net>, Eric Biederman <ebiederm@...ssion.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jslaby@...e.com>, Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>, linux-kernel@...r.kernel.org, Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> Subject: Re: [RFC][PATCHv2 3/8] printk: offload printing from wake_up_klogd_work_func() On Wed 2017-03-29 18:25:06, Sergey Senozhatsky wrote: > Offload printing of printk_deferred() messages from IRQ context > to a schedulable printing kthread, when possible (the same way > we do it in vprintk_emit()). Otherwise, console_unlock() can > force the printing CPU to spend unbound amount of time flushing > kernel messages from IRQ context. > > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@...il.com> > --- > kernel/printk/printk.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index ab6b3b2a68c6..1927b5cb5cbe 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -2741,8 +2741,16 @@ static void wake_up_klogd_work_func(struct irq_work *irq_work) > * If trylock fails, someone else is doing the printing. > * PRINTK_PENDING_OUTPUT bit is cleared by console_unlock(). > */ > - if (console_trylock()) > - console_unlock(); > + if (printk_kthread_enabled()) { > + wake_up_process(printk_kthread); Note that the relation between printk_kthread_enabled() and wake_up_process() is racy. The conditions might change between these two calls. It looks fine here, well almost. The critical point is in vprintk_emit(). It must use the emergency mode (call the consoles directly) when it is called from a process that started the emergency mode. We could be more relaxed here. IMHO, the only sensitive situation is if printk_deferred() is used in the emergency context. We might want to use the emergency mode here as well but it is not guaranteed. printk_emergency might get cleared in the meantime. A solution might be to add one more bit, e.g. PRINTK_PENDING_EMERGENCY_OUTPUT. We should force the emergency mode here when it is set. It should be cleared together with the normal PRINTK_PENDING_OUTPUT. Or do you think that this is a corner case that we could ignore for now? Otherwise, it looks fine to me. Best Regards, Petr
Powered by blists - more mailing lists