Messages in this thread |  | | | Date | Sat, 14 Jan 2006 20:24:49 -0800 | | Subject | Re: RT Mutex patch and tester [PREEMPT_RT] | | From | Bill Huey (hui) <> |
| |
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 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 ?
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/
|  |