![]() | |||||||||||||
Messages in this thread |
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 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/ > - 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/ | ||||||||||||
| Last update: 2006-01-16 09:39 [from the cache] ©2003-2008 | |||||||||||||