Philip Blundell (philb@gnu.org)
Sun, 12 Jul 1998 21:37:55 +0100
>I start another one going, and copied all of the files on the Zip disk to
>/dev/null. I've now managed to get the user-space program to stop, and
>it's in D-state.
I took a quick look at this. I haven't traced the code through properly yet
and my memory of how it works is a bit fuzzy, but this looks slightly dubious
to me:
/* If anybody is waiting, find out who's been there longest and
then wake them up. (Note: no locking required) */
for (pd = port->waithead; pd; pd = pd->waitnext) {
if (pd->waiting & 2) {
parport_claim(pd);
if (waitqueue_active(&pd->wait_q))
wake_up(&pd->wait_q);
return;
} else if (pd->wakeup) {
pd->wakeup(pd->private);
if (dev->port->cad)
return;
} else {
printk(KERN_ERR "%s: don't know how to wake %s\n", port->name, pd->name);
}
}
I think the `pd->waiting & 2' conditional should actually be `pd->waiting & 1'.
Bit 1 is just a magic way for parport_claim_and_block() to signal to
parport_claim() that it wants to wait; it doesn't mean we've actually gotten
added to a wait-queue yet. This means there's a window of opportunity for
parport_release() to get called, find waiting==2 and give that device the port
while the other thread is somewhere in parport_claim but hasn't yet got to the
spin_lock_irqsave at line 352.
I'm not sure whether correcting that will solve all the problems though, there
may still be a race condition lurking. I'll need to look more at it.
p.
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:17:57 EST