On Sun, Mar 20, 2005 at 05:57:23PM +0100, Manfred Spraul wrote:
> That was just one random example.
> Another one would be :
>
> drivers/chat/tty_io.c, __do_SAK() contains
> read_lock(&tasklist_lock);
> task_lock(p);
>
> kernel/sys.c, sys_setrlimit contains
> task_lock(current->group_leader);
> read_lock(&tasklist_lock);
>
> task_lock is a shorthand for spin_lock(&p->alloc_lock). If read_lock is
> a normal spinlock, then this is an A/B B/A deadlock.
That code was already dubious in the first place just because it
contained that circularity. If you had a rwlock that block on an
upper read count maximum a deadlock situation would trigger anyways,
say, upon a flood of threads trying to do that sequence of aquires.
I'd probably experiment with using the {spin,read,write}-trylock
logic and release the all locks contains in a sequence like that
on the failure to aquire any of the locks in the chain as an
initial fix. A longer term fix might be to break things up a bit
so that whatever ordering being done would have that circularity.
BTW, the runtime lock cricularity detector was designed to trigger
on that situtation anyways.
That's my thoughts on the matter.
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/
