Re: [PARPORT] lp locks with three devs on parport

Philip Blundell (
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) {
                        if (waitqueue_active(&pd->wait_q))
                } else if (pd->wakeup) {
                        if (dev->port->cad)
                } 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.


-- To unsubscribe, send mail to: --
-- 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