From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933630AbcATMi2 (ORCPT ); Wed, 20 Jan 2016 07:38:28 -0500 Received: from mx2.suse.de ([195.135.220.15]:38671 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751205AbcATMiY (ORCPT ); Wed, 20 Jan 2016 07:38:24 -0500 Date: Wed, 20 Jan 2016 13:38:21 +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: <20160120123821.GW731@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> <20160118161744.GZ3178@pathway.suse.cz> <20160119011510.GB4963@swordfish> <20160119151801.GB2148@dhcp128.suse.cz> <20160120035056.GA506@swordfish> <20160120115143.GA2668@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160120115143.GA2668@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 Wed 2016-01-20 20:51:43, Sergey Senozhatsky wrote: > On (01/20/16 12:50), Sergey Senozhatsky wrote: > [..] > > > Hmm, the notifiers are called via __raw_notifier_call_chain(). > > > There is a comment above this function: > > > > > > * Calls each function in a notifier chain in turn. The functions > > > * run in an undefined context. > > > * All locking must be provided by the caller. > > > > > > But hmm, you are right that the notifiers do malloc, take mutextes, > > > etc. The question is if schedule does something in this case. I would > > > expect that the is no running task assigned to this CPU at this stage. > > > So, cond_resched is probably a noop in this case. > > I did some modifications to notifier, just to check how real that theoretical > race condition can possible be. After all I think that this was a false alarm. As you said, there are used locks in the notifiers. I do not see any special handling of preemption. If the locks do not care about this special CPU state and rescheduling, printk should not need to take care of it as well. In each case, thanks a lot for the analyze. These are all interesting things and any piece of information helps better understanding. Best Regards, Petr