Re: Race conditions galore (2.0.33 and possibly 2.1.x)

Bill Hawes (whawes@star.net)
Mon, 22 Dec 1997 11:23:29 -0500


Stephen R. van den Berg wrote:
> Could someone who created these wait-queue loops (there are several of them
> in the kernel, potentially all of them are race conditions waiting to
> happen) confirm if I'm reading this correctly? Maybe I still overlooked
> possible problems, but it seems like this is the minimally-correct change.

In this particular case the existing code should be OK. The reason you
don't need to set the task state to TASK_UNINTERRUPTIBLE in advance is
that we have a test available for whether to do the reschedule: if the
buffer is already unlocked, there's no need to schedule. In the event an
interrupt occurs in between the test for buffer locked and the
schedule() call, the resulting wakeup() will set the task state back to
TASK_RUNNING, and we'll fall through the schedule().

If no test exists for whether or not to do a schedule(), then you need
to set the task state prior to adding the task to the wait queue. Then
any wakeups from an interrupt will set the task state back to running.

Regards,
Bill