From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755788AbcARQRs (ORCPT ); Mon, 18 Jan 2016 11:17:48 -0500 Received: from mx2.suse.de ([195.135.220.15]:41835 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755614AbcARQRq (ORCPT ); Mon, 18 Jan 2016 11:17:46 -0500 Date: Mon, 18 Jan 2016 17:17:44 +0100 From: Petr Mladek To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Andrew Morton , Tejun Heo , Jan Kara , Kyle McMartin , Dave Jones , Calvin Owens , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of console_trylock callers Message-ID: <20160118161744.GZ3178@pathway.suse.cz> References: <1452747443-9927-1-git-send-email-sergey.senozhatsky@gmail.com> <1452747443-9927-3-git-send-email-sergey.senozhatsky@gmail.com> <20160117141137.GA631@swordfish> <20160117142332.GA543@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160117142332.GA543@swordfish> 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 Sun 2016-01-17 23:23:32, Sergey Senozhatsky wrote: > console_unlock() allows to cond_resched() if its caller has > set `console_may_schedule' to 1 (this functionality present > since commit 'printk: do cond_resched() between lines while > outputting to consoles'). > > The rules are: > -- console_lock() always sets `console_may_schedule' to 1 > -- console_trylock() always sets `console_may_schedule' to 0 > > However, console_trylock() callers (among them is printk()) are > not necessarily executing in atomic contexts, and some of them > can cond_resched() in console_unlock(). So console_trylock() > can set `console_may_schedule' to 0 only if cond_resched() is > invalid in the current context, and set it to 1 otherwise. > > The patch also drops explicit preempt_disable()/preempt_enable() > calls in vprintk_emit(). I do not see any explanation why it is safe to remove these calls in this patch. If they were required only because of the can_use_console() call, it would make sense to move this change to the previous patch. The previous patch moved the can_use_console() to locations protected by lockbuf_lock that have disabled preemption because of the lock. > Signed-off-by: Sergey Senozhatsky > --- > V2: rcu_preempt_depth() on preempt RCU kernels > > kernel/printk/printk.c | 13 ++++--------- > 1 file changed, 4 insertions(+), 9 deletions(-) > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index ae641d7..9ac05e0 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -1777,20 +1777,12 @@ asmlinkage int vprintk_emit(int facility, int level, > if (!in_sched) { > lockdep_off(); > /* > - * Disable preemption to avoid being preempted while holding > - * console_sem which would prevent anyone from printing to > - * console > - */ > - preempt_disable(); > - > - /* > * Try to acquire and then immediately release the console > * semaphore. The release will print out buffers and wake up > * /dev/kmsg and syslog() users. > */ > if (console_trylock_for_printk()) > console_unlock(); > - preempt_enable(); > lockdep_on(); > } > > @@ -2123,7 +2115,10 @@ int console_trylock(void) > return 0; > } > console_locked = 1; > - console_may_schedule = 0; > + console_may_schedule = !(oops_in_progress || > + irqs_disabled() || > + in_atomic() || > + rcu_preempt_depth()); Is it safe to call cond_resched() when the CPU is not online and preemption is enabled, please? Your previous patch suggests that this situation might happen. I guess that it might break the CPU initialization code. Best Regards, Petr > return 1; > } > EXPORT_SYMBOL(console_trylock); > -- > 2.7.0 >