From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756903AbcASBOD (ORCPT ); Mon, 18 Jan 2016 20:14:03 -0500 Received: from mail-pf0-f170.google.com ([209.85.192.170]:36739 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756599AbcASBOA (ORCPT ); Mon, 18 Jan 2016 20:14:00 -0500 Date: Tue, 19 Jan 2016 10:15:10 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , 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: <20160119011510.GB4963@swordfish> 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> <20160118161744.GZ3178@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160118161744.GZ3178@pathway.suse.cz> 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 Thanks for the review. On (01/18/16 17:17), Petr Mladek wrote: > 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 The comment in the code states /* * Disable preemption to avoid being preempted while holding * console_sem which would prevent anyone from printing to * console */ which is not really a problem -- we schedule from console_unlock() with the console_sem being held, it's fine. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/printk/printk.c?id=8d91f8b15361dfb438ab6eb3b319e2ded43458ff > 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. old: vprintk_emit preempt_disable can_use_console console_unlock spin_lock, save IRQ spin_unlock call_console_drivers restore IRQ preempt_enable new: vprintk_emit console_unlock spin_lock, save IRQ can_use_console spin_unlock call_console_drivers restore IRQ so preemption is disabled during the transition from can_use_console() to call_console_drivers(). [..] > > 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. CPU notifies are preemptible. CPU_UP_PREPARE/etc. can schedule, there are GFP_KERNEL kmalloc-s from CPU_UP_PREPARE (where cpu is not yet online), mutex_lock() calls in cpu_notify handlers, and so on. -ss