Possible race in sound/oss/forte.c ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux