Possible race in sound/oss/forte.c ?

[John M. King]

I know the OSS drivers are deprecated, but I'm trying to figure this out
for my own understanding.

Here's code from sound/oss/forte.c, in the write system call handler.  A
test has already been performed (under the protection of the lock) and
the driver has decided to sleep.

    add_wait_queue (&channel->wait, &wait);

    for (;;) {
        spin_unlock_irqrestore (&chip->lock, flags);

        set_current_state (TASK_INTERRUPTIBLE);
        schedule();

        spin_lock_irqsave (&chip->lock, flags);

        if (channel->frag_num - channel->filled_frags)
            break;
    }

    remove_wait_queue (&channel->wait, &wait);
    set_current_state (TASK_RUNNING);

The driver's interrupt handler calls wake_up_all().  What if an
interrupt occurs just after the spin_unlock_irqrestore() but before
setting TASK_INTERRUPTIBLE (and the interrupt handler does stuff that
causes the tested conditional to be true as well)?  The interrupt calls
wake_up_all(), but then when control returns here, the process will mark
itself TASK_INTERRUPTIBLE right away and sleep, effectively missing the
wake_up_all().

Is this a race condition?  If not, can someone point out the error(s) in
my reasoning?  Please CC me as I'm not subscribed to the list.

Thanks,
John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/