From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758814AbcAUFui (ORCPT ); Thu, 21 Jan 2016 00:50:38 -0500 Received: from mail-pa0-f45.google.com ([209.85.220.45]:33570 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758520AbcAUFue (ORCPT ); Thu, 21 Jan 2016 00:50:34 -0500 Date: Thu, 21 Jan 2016 14:51:46 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Andrew Morton , Tejun Heo , Jan Kara , Kyle McMartin , Dave Jones , Calvin Owens , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCH -next 2/2] printk: set may_schedule for some of console_trylock callers Message-ID: <20160121055146.GA398@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> <20160119011510.GB4963@swordfish> <20160119151801.GB2148@dhcp128.suse.cz> <20160120035056.GA506@swordfish> <20160120123107.GB3305@pathway.suse.cz> <20160121012551.GA594@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160121012551.GA594@swordfish> 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 (01/21/16 10:25), Sergey Senozhatsky wrote: [..] > > First, the message "This stops the holder of console_sem just where we > > want him" is suspitious. > > this comment is irrelevant, as of today. it was, a long time ago, because > the entire thing was a bit different (linux-2.4.21 kernel/printk.c) > > /* This stops the holder of console_sem just where we want him */ > spin_lock_irqsave(&logbuf_lock, flags); > > logbuf_lock does stop the holder, local_irq_save() does not, you are right. I meant 'irrelevant on its current place'. [..] > > As a result, I think that we do not need the extra checks > > for the save context in printk(). IMHO, it is safe to remove > > all the console_may_schedule stuff and also remove the extra > > preempt_disable/preempt_enable() in vprintk_emit(). > > > > Or did I miss anything? > > hm... I suspect the reason we have console_may_schedule is > console_conditional_schedule() - console_sem owner may want > to have an internal logic to re-schedule [fwiw], while still > holding the console_sem. tty/vt/vt.c or video/console/fbcon.c > for example. (in 2.4 kernel: video/fbcon.c and char/console.c). > > cond_resched() helps in console_unlock(); console_conditional_schedule() > is called after console_lock() and _before_ console_unlock().... for CONFIG_PREEMPT_COUNT kernel we can do something like +void __sched console_conditional_schedule(void) +{ + if (!oops_in_progress && preemptible() && !rcu_preempt_depth()) + cond_resched(); +} and in console_unlock() - if (do_cond_resched) - cond_resched(); + console_conditional_schedule(); but for !CONFIG_PREEMPT_COUNT we can't. because of currently held spin_locks/etc that we don't know about. `console_may_schedule' carries a bit of important information for console_conditional_schedule() caller. if it has acquired console_sem via console_lock() - then it can schedule, if via console_trylock() - it cannot. the last `if via console_trylock() - it cannot' rule is not always true, we clearly can have printk()->console_unlock() from non-atomic contexts (if we know that its non-atomic, which is not the case with !PREEMPT_COUNT). -ss