From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751336AbdAPL71 (ORCPT ); Mon, 16 Jan 2017 06:59:27 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:36491 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750982AbdAPL7W (ORCPT ); Mon, 16 Jan 2017 06:59:22 -0500 Date: Mon, 16 Jan 2017 20:58:44 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Tetsuo Handa , Steven Rostedt , Peter Zijlstra , Andrew Morton , Greg Kroah-Hartman , Jiri Slaby , linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] printk: Correctly handle preemption in console_unlock() Message-ID: <20170116115844.GA405@tigerII.localdomain> References: <1484313321-17196-1-git-send-email-pmladek@suse.com> <20170114062825.GB699@tigerII.localdomain> <20170116113834.GF20462@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170116113834.GF20462@pathway.suse.cz> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (01/16/17 12:38), Petr Mladek wrote: [..] > > > Now, @console_may_schedule is not cleared when we call > > > console_trylock() and jump back to the "again" goto label. > > > This has become a problem, since the commit 6b97a20d3a7909daa066 > > > ("printk: set may_schedule for some of console_trylock() callers"). > > > > so I think I'd prefer to revert that commit. > > > > the reason I added the commit in question was to reduce the number of > > printk() soft lockups that I observed back then. however, it obviously > > didn't solve all of the printk() problems. > > Interesting idea! > > > now printk() is moving in a > > completely different direction in term of lockups and deadlocks. there > > will be no console_trylock() call in vprintk_emit() at all. we will > > either do console_lock() from scheduleable printk_kthread or > > console_trylock() from IRQ work. so 6b97a20d3a7909daa066 didn't buy us > > a lot, and it still doesn't (+ it introduced a bug). > > Well, console_trylock() still will be there for the sync mode. > Or do I miss anything? you mean in console_unlock()? there we inherit may_schedule from the original console_sem lock path, which sould be console_lock() in async printk case (IOW, preemptible). other then that - from printk POV, I don't think we will care that much. anything that directly calls console_lock()/console_trylock will be doing console_unlock(). those paths are not addressed by async printk anyway. I have some plans on addressing it, as you know, but that's a later work. so let's return good ol' bhaviour: -- console_trylock is always "no resched" -- console_lock is always "enable resched" (regardless of console_trylock calls from console_unlock()). > > apart from that, Tetsuo wasn't really happy with the patch > > http://www.spinics.net/lists/linux-mm/msg103099.html > > The complain is questionable. If a code is sensitive for preemption, > it should disable preemption. > > Another question is if people expect that printk() would call > cond_resched() or preempt. my assumption would be that probably people expect printk to work asap. [..] > This would revert the change only for non-preemptive kernel. > > The commit 6b97a20d3a7909daa06625 ("printk: set may_schedule for some > of console_trylock() callers" also enabled preemption which still > affects preemtible kernel. > > Do we want to behave differently in preemptive and non-preemtive > kernel? not sure I'm following here. in non-preemptible kernels console_trylock() always sets console_may_schedule to 0, just like it did before. in preemptible kernels we now will also set console_may_schedule to 0. just like before. in any case, we return back the old behavior. there should be no issues (tm) -ss