This is a note to let you know that I've just added the patch titled
klist: del waiter from klist_remove_waiters before wakeup waitting process
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
klist-del-waiter-from-klist_remove_waiters-before-wakeup-waitting-process.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From ac5a2962b02f57dea76d314ef2521a2170b28ab6 Mon Sep 17 00:00:00 2001
From: "wang, biao" <biao.wang@xxxxxxxxx>
Date: Thu, 16 May 2013 09:50:13 +0800
Subject: klist: del waiter from klist_remove_waiters before wakeup waitting process
From: "wang, biao" <biao.wang@xxxxxxxxx>
commit ac5a2962b02f57dea76d314ef2521a2170b28ab6 upstream.
There is a race between klist_remove and klist_release. klist_remove
uses a local var waiter saved on stack. When klist_release calls
wake_up_process(waiter->process) to wake up the waiter, waiter might run
immediately and reuse the stack. Then, klist_release calls
list_del(&waiter->list) to change previous
wait data and cause prior waiter thread corrupt.
The patch fixes it against kernel 3.9.
Signed-off-by: wang, biao <biao.wang@xxxxxxxxx>
Acked-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
lib/klist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/klist.c
+++ b/lib/klist.c
@@ -193,10 +193,10 @@ static void klist_release(struct kref *k
if (waiter->node != n)
continue;
+ list_del(&waiter->list);
waiter->woken = 1;
mb();
wake_up_process(waiter->process);
- list_del(&waiter->list);
}
spin_unlock(&klist_remove_lock);
knode_set_klist(n, NULL);
Patches currently in stable-queue which might be from biao.wang@xxxxxxxxx are
queue-3.4/klist-del-waiter-from-klist_remove_waiters-before-wakeup-waitting-process.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html