Re: lock_kernel() / unlock_kernel inconsistency Don't do this!

[george anzinger <george@mvista.com>]

Alan Cox wrote:
> 
> > Both of these methods have problems, especially with the proposed
> > preemptions changes.  The first case causes the thread to run with the
> > BKL for the whole time.  This means that any other task that wants the
> > BKL will be blocked.  Surly the needed protections don't require this.
> 
> The BKL is dropped on rescheduling of that task. Its an enforcement of the
> old unix guarantees against other code making the same assumptions. Its also
> the standard 2.4 locking for several things still
> 
Yes, I am aware of the drop on schedule, but a preemptive schedule call
should (can not) do this.  Result, no preemption, i.e. the thread does
not let anyone else in.  Some how I don't think a long term hold, such
as this is needed.  Of course, if the code blocks (i.e. calls
schedule()) often... but then we find folks using such code a pattern
and learning tool.  Remember this thread was started by just such a
study.

George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/