linux-kernel - [PATCH 1/2] kthread: add a missing memory barrier to kthread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Feb 2008 22:36:30 +0100
From:	Dmitry Adamushko <dmitry.adamushko@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Cc:	Nick Piggin <nickpiggin@...oo.com.au>, Ingo Molnar <mingo@...e.hu>,
	Rusty Russel <rusty@...tcorp.com.au>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andy Whitcroft <apw@...dowen.org>, dmitry.adamushko@...il.com
Subject: [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop()

From: Dmitry Adamushko <dmitry.adamushko@...il.com>
Subject: kthread: add a missing memory barrier to kthread_stop()
    
We must ensure that kthread_stop_info.k has been updated before
kthread's wakeup. This is required to properly support
the use of kthread_should_stop() in the main loop of kthread.
    
wake_up_process() doesn't imply a full memory barrier,
so we add an explicit one.
    
There is a requirement on how a main loop of kthread has to be orginized.
    
Namely, the sequence of events that lead to kthread being blocked (schedule())
has to be ordered as follows:
    
- set_current_state(TASK_INTERRUPTIBLE);
- if (kthread_should_stop()) break;
- schedule() or similar.
    
set_current_state() implies a full memory barrier, so this is
a matching barrier on the side of kthread_should_stop().
    
Signed-off-by: Dmitry Adamushko <dmitry.adamushko@...il.com>


diff --git a/kernel/kthread.c b/kernel/kthread.c
index 45f8b83..86b69a0 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -53,6 +53,19 @@ static struct kthread_stop_info kthread_stop_info;
  * When someone calls kthread_stop() on your kthread, it will be woken
  * and this will return true.  You should then return, and your return
  * value will be passed through to kthread_stop().
+ *
+ * In order to safely use kthread_stop() for kthread, there is a requirement
+ * on how its main loop has to be orginized. Namely, the sequence of
+ * events that lead to kthread being blocked (schedule()) has to be
+ * ordered as follows:
+ *
+ * - set_current_state(TASK_INTERRUPTIBLE);
+ * - if (kthread_should_stop()) break;
+ * - schedule() or similar.
+ *
+ * set_current_state() implies a full memory barrier. kthread_stop()
+ * has a matching barrier right after an update of kthread_stop_info.k
+ * and before kthread's wakeup.
  */
 int kthread_should_stop(void)
 {
@@ -211,6 +224,15 @@ int kthread_stop(struct task_struct *k)
 
 	/* Now set kthread_should_stop() to true, and wake it up. */
 	kthread_stop_info.k = k;
+
+	/* 
+	 * We must ensure that kthread_stop_info.k has been updated before
+	 * the following wakeup. This is required to properly support the use
+	 * of kthread_should_stop() in the main loop of kthread
+	 * (see description of kthread_should_stop() for more details).
+	 */
+	smp_mb();
+
 	wake_up_process(k);
 	put_task_struct(k);
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/