On 16 Sep 2002, Robert Love wrote:
>
> I was this -> <- close to celebrating. Not so fast, smarty.
You forget - I'm not only a smarty, I'm sick and twisted too.
> What about release_kernel_lock() ?
>
> It sees task->lock_depth>=0 and calls spin_unlock() on a lock that it
> does not hold.
We have a simple rule:
- task->lock_depth = -1 means "no lock held"
- task->lock_depth >= 0 means "BKL really held"
... but what does "task->lock_depth < -1" mean?
Yup: "validly nonpreemptable".
So then you have:
#define kernel_locked() (current->lock_depth >= 0)
#define in_atomic() (preempt_count() & ~PREEMPT_ACTIVE) != (current->lock_depth != -1))
and you're all set - just set lock_depth to -2 when you exit to show that
you don't hold the BKL, but that you are validly not preemtable.
I get the award for having the most disgusting ideas.
Linus "but it works and is efficient" Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:18 EST