Messages in this thread |  | | | Date | Mon, 22 Dec 1997 11:23:29 -0500 | | From | Bill Hawes <> | | Subject | Re: Race conditions galore (2.0.33 and possibly 2.1.x) |
| |
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
|  |