Messages in this thread | | | Date | Mon, 22 Dec 1997 17:59:49 +0100 | From | "Stephen R. van den Berg" <> | Subject | Re: Race conditions galore (2.0.33 and possibly 2.1.x) |
| |
Bill Hawes wrote: >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
Obviously.
>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().
This I'm not certain about. I only performed a cursory check of schedule.c, but it seems that when the task is still on the run-queue (which it is, before it hits schedule()), the task state will *not* be set back to TASK_RUNNING.
Also, what happens if the same buffer is: 1. Locked. 2. We add ourselves to the wait queue. 3. The buffer is unlocked. 4. We are set to TASK_RUNNING. 5. Someone else locks the buffer. 6. We set ourselves to TASK_UNINTERRUPTIBLE. 7. We check the lock. 8. We drop dead in schedule().
Or am I seeing ghosts?
Note: I wouldn't be beating around about this so much, if it weren't for the fact that I have a machine here that actually *repeatedly* had processes hanging in constructs like this. I patched it as described, and the problems have not recurred yet (maybe that's just a coincidence, or maybe I even did something I shouldn't have been doing in the first place).
The only other thing it could be would be a hardware-failure of some kind (RAM-biterrors being unlikely, I'm using ECC; most likely something strange the SCSI driver was not expecting; but, the kernel did not log a single error). -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"Father's Day: Nine months before Mother's Day."
| |