From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933302AbdCaO4H (ORCPT ); Fri, 31 Mar 2017 10:56:07 -0400 Received: from mx2.suse.de ([195.135.220.15]:57347 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933114AbdCaO4G (ORCPT ); Fri, 31 Mar 2017 10:56:06 -0400 Date: Fri, 31 Mar 2017 16:56:02 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Steven Rostedt , Jan Kara , Andrew Morton , Linus Torvalds , Peter Zijlstra , "Rafael J . Wysocki" , Eric Biederman , Greg Kroah-Hartman , Jiri Slaby , Pavel Machek , Len Brown , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCHv2 3/8] printk: offload printing from wake_up_klogd_work_func() Message-ID: <20170331145602.GB3452@pathway.suse.cz> References: <20170329092511.3958-1-sergey.senozhatsky@gmail.com> <20170329092511.3958-4-sergey.senozhatsky@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170329092511.3958-4-sergey.senozhatsky@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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