[lkml]   [1997]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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


>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

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

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).
Stephen R. van den Berg (AKA BuGless).

"Father's Day: Nine months before Mother's Day."

 \ /
  Last update: 2005-03-22 13:40    [W:0.100 / U:8.012 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site