From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754790AbcCNHK6 (ORCPT ); Mon, 14 Mar 2016 03:10:58 -0400 Received: from mx2.suse.de ([195.135.220.15]:54201 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751185AbcCNHKv (ORCPT ); Mon, 14 Mar 2016 03:10:51 -0400 Date: Mon, 14 Mar 2016 08:11:11 +0100 From: Jan Kara To: Sergey Senozhatsky Cc: Andrew Morton , Jan Kara , Petr Mladek , Tejun Heo , Tetsuo Handa , linux-kernel@vger.kernel.org, Sergey Senozhatsky , Jan Kara Subject: Re: [RFC][PATCH v3 1/2] printk: Make printk() completely async Message-ID: <20160314071111.GB5213@quack.suse.cz> References: <1457876087-26929-1-git-send-email-sergey.senozhatsky@gmail.com> <1457876087-26929-2-git-send-email-sergey.senozhatsky@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1457876087-26929-2-git-send-email-sergey.senozhatsky@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun 13-03-16 22:34:46, Sergey Senozhatsky wrote: > + /* > + * By default we print message to console asynchronously so that kernel > + * doesn't get stalled due to slow serial console. That can lead to > + * softlockups, lost interrupts, or userspace timing out under heavy > + * printing load. > + * > + * However we resort to synchronous printing of messages during early > + * boot, when synchronous printing was explicitly requested by > + * kernel parameter, or when console_verbose() was called to print > + * everything during panic / oops. > + */ > + if (!sync_print) { > + if (printk_thread && !in_panic) { > + /* > + * Wakeup the printing kthread and offload printing > + * to a schedulable context. > + */ > + wake_up(&printing_wait); > + } else if (in_sched) { > + /* > + * @in_sched messages may come too early, when we don't > + * yet have @printk_thread. We can't print deferred > + * messages directly, because this may deadlock, route > + * them via IRQ context. > + */ > + __this_cpu_or(printk_pending, > + PRINTK_PENDING_OUTPUT); > + irq_work_queue(this_cpu_ptr(&wake_up_klogd_work)); You cannot call wake_up() from a scheduler context - i.e., if in_sched is true, you have to use irq work unconditionally. You can wake up kthread from irq work or just directly print the message there. Otherwise the patch looks fine. Honza -- Jan Kara SUSE Labs, CR