diff options
| author | David Woodhouse <David.Woodhouse@intel.com> | 2008-11-07 00:08:59 +0000 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@suse.de> | 2008-11-13 09:55:58 -0800 |
| commit | ffda96ca180ee1def996fd9a63c5a3d620caf223 (patch) | |
| tree | 2a0ec49cfe89c1016de096438b1f984bcbd77835 | |
| parent | a414c208c07d29b404d07665ea6ab1bc564ade42 (diff) | |
JFFS2: Fix lack of locking in thread_should_wake()
commit b27cf88e9592953ae292d05324887f2f44979433 upstream
The thread_should_wake() function trawls through the list of 'very
dirty' eraseblocks, determining whether the background GC thread should
wake. Doing this without holding the appropriate locks is a bad idea.
OLPC Trac #8615
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| -rw-r--r-- | fs/jffs2/background.c | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c index 8adebd3e43c6..0fd792bcb519 100644 --- a/fs/jffs2/background.c +++ b/fs/jffs2/background.c @@ -85,15 +85,15 @@ static int jffs2_garbage_collect_thread(void *_c) for (;;) { allow_signal(SIGHUP); again: + spin_lock(&c->erase_completion_lock); if (!jffs2_thread_should_wake(c)) { set_current_state (TASK_INTERRUPTIBLE); + spin_unlock(&c->erase_completion_lock); D1(printk(KERN_DEBUG "jffs2_garbage_collect_thread sleeping...\n")); - /* Yes, there's a race here; we checked jffs2_thread_should_wake() - before setting current->state to TASK_INTERRUPTIBLE. But it doesn't - matter - We don't care if we miss a wakeup, because the GC thread - is only an optimisation anyway. */ schedule(); - } + } else + spin_unlock(&c->erase_completion_lock); + /* This thread is purely an optimisation. But if it runs when other things could be running, it actually makes things a |