lkml.org 
[lkml]   [1997]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRace conditions galore (2.0.33 and possibly 2.1.x)
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.

The following patch seems to get rid of a race condition (you need several
more to clear out all similar race conditions in the kernel):

diff /work/linux/linuxref/fs/buffer.c -> buffer.c
--- /work/linux/linuxref/fs/buffer.c Fri Dec 12 03:54:40 1997
+++ /work/linux/linux/fs/buffer.c Mon Dec 22 01:38:24 1997
@@ -115,12 +115,13 @@
struct wait_queue wait = { current, NULL };

bh->b_count++;
+ current->state = TASK_UNINTERRUPTIBLE;
add_wait_queue(&bh->b_wait, &wait);
repeat:
run_task_queue(&tq_disk);
- current->state = TASK_UNINTERRUPTIBLE;
if (buffer_locked(bh)) {
schedule();
+ current->state = TASK_UNINTERRUPTIBLE;
goto repeat;
}
remove_wait_queue(&bh->b_wait, &wait);
I didn't check the sources for 2.1.x yet, but quite possibly it contains
similarly flawed constructs.
--
Sincerely, srb@cuci.nl
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.985 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site