> > this one looks like a place that relies on the 'old' behavior of
> > sleep_on*? We go into interruptible_sleep_on() with interrupts disabled,
> > and if sleep_on() write-locks on waitqueue_lock, another CPU read-locks
> > waitqueue_lock and is interrupted, then that IRQ or bh deadlocks, boom.
>
> If you write-lock on waitqueue-lock, then you will release the lock and
> try again. A write lock will never wait with the lock held, so the other
> CPU should not read-lock. See the write_lock(rw) implementation:
yes but it will loop forever. This means we will not 'progress' and the
interrupt lock will not be released:
CPU0 CPU1
read_lock(l);
...... cli();
do_IRQ() ......
write_lock(l);
< lockup >
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/