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