>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."