On Sat, 14 Jan 2006, Bill Huey wrote:
> On Wed, Jan 11, 2006 at 06:25:36PM +0100, Esben Nielsen wrote:
> > So how many locks do we have to worry about? Two.
> > One for locking the lock. One for locking various PI related data on the
> > task structure, as the pi_waiters list, blocked_on, pending_owner - and
> > also prio.
> > Therefore only lock->wait_lock and sometask->pi_lock will be locked at the
> > same time. And in that order. There is therefore no spinlock deadlocks.
> > And the code is simpler.
>
> Ok, got a question. How do deal with the false reporting and handling of
> a lock circularity window involving the handoff of task A's BKL to another
> task B ? Task A is blocked trying to get a mutex owned by task B, task A
> is block B since it owns BKL which task B is contending on. It's not a
> deadlock since it's a hand off situation.
>
I am not precisely sure what you mean by "false reporting".
Handing off BKL is done in schedule() in sched.c. I.e. if B owns a normal
mutex, A will give BKL to B when A calls schedule() in the down-operation
of that mutex.
> I didn't see any handling of this case in the code and I was wondering
> if the traversal logic you wrote avoids this case as an inherent property
> and I missed that stuff ?
The stuff is in kernel/sched.c and lib/kernel_lock.c.
>
> bill
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
