Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do | Date | Tue, 19 Oct 2010 15:57:56 +0200 |
| |
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
| |