]> pilppa.com Git - linux-2.6-omap-h63xx.git/commitdiff
[JFFS2] Fix lack of locking in thread_should_wake()
authorDavid Woodhouse <David.Woodhouse@intel.com>
Fri, 31 Oct 2008 14:52:24 +0000 (14:52 +0000)
committerDavid Woodhouse <David.Woodhouse@intel.com>
Fri, 31 Oct 2008 14:52:24 +0000 (14:52 +0000)
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
fs/jffs2/background.c

index 8adebd3e43c690fbf0469cf9b235279998c252c8..3cceef4ad2b7df413e98b8171cadf074de83ad2d 100644 (file)
@@ -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