[lkml]   [2002]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] BUG(): sched.c: Line 944

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.066 / U:0.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site