From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do Date: Tue, 19 Oct 2010 15:57:56 +0200 Message-ID: <201010191557.56584.arnd@arndb.de> References: <201009161632.59210.arnd@arndb.de> <201010191536.33373.arnd@arndb.de> <1287495832.16971.368.camel@gandalf.stny.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by gabe.freedesktop.org (Postfix) with ESMTP id 5B6299E769 for ; Tue, 19 Oct 2010 06:57:23 -0700 (PDT) In-Reply-To: <1287495832.16971.368.camel@gandalf.stny.rr.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Steven Rostedt Cc: Greg KH , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Christoph Hellwig , ksummit-2010-discuss@lists.linux-foundation.org List-Id: dri-devel@lists.freedesktop.org On Tuesday 19 October 2010, Steven Rostedt wrote: > On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote: > > [trimming Cc list] > > > > On Tuesday 19 October 2010, Steven Rostedt wrote: > > > I think we also need to cover the PREEMPT case too. But that could be a > > > compile time check, since you can't boot a preempt kernel and make it > > > non preempt. > > > > Right. Can we turn the lock_kernel() into preempt_disable() in these > > drivers when we know we never run on SMP? > > I'm not sure that will work. A holder of the BKL can call schedule or > even a mutex. The schedule code will drop the BKL and re-enable > preemption. Unless the code is known not to schedule while holding BKL, > we would need to open code the preempt_enable() around the locations > that the code may schedule. Right, that won't work then. I was confused by the fact that __lock_kernel() turns into preempt_disable() on UP-preempt systems, which only works because it still maintains current->lock_depth and schedule consequently enables preemption again in __release_kernel_lock(). With CONFIG_BKL disabled, that won't happen any more. Arnd