summaryrefslogtreecommitdiffstats
path: root/fs/jffs2/background.c
diff options
context:
space:
mode:
authorDavid Woodhouse <David.Woodhouse@intel.com>2008-10-31 14:52:24 +0000
committerDavid Woodhouse <David.Woodhouse@intel.com>2008-10-31 14:52:24 +0000
commitb27cf88e9592953ae292d05324887f2f44979433 (patch)
tree9f903a17a08801197127b479429ee2e304898799 /fs/jffs2/background.c
parentf04de505e3fa322728d1a851e08bf7060b117743 (diff)
downloadlinux-b27cf88e9592953ae292d05324887f2f44979433.tar.bz2
[JFFS2] Fix lack of locking in thread_should_wake()
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> Cc: stable@kernel.org
Diffstat (limited to 'fs/jffs2/background.c')
-rw-r--r--fs/jffs2/background.c10
1 files changed, 5 insertions, 5 deletions
diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
index 8adebd3e43c6..3cceef4ad2b7 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