linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop()
@ 2008-02-20 21:36 Dmitry Adamushko
  2008-03-02 21:50 ` Rusty Russell
  0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Adamushko @ 2008-02-20 21:36 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel
  Cc: Nick Piggin, Ingo Molnar, Rusty Russel, Paul E. McKenney,
	Peter Zijlstra, Andy Whitcroft, dmitry.adamushko

From: Dmitry Adamushko <dmitry.adamushko@gmail.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@gmail.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);
 



^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop()
  2008-02-20 21:36 [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop() Dmitry Adamushko
@ 2008-03-02 21:50 ` Rusty Russell
  2008-03-02 22:28   ` Dmitry Adamushko
  0 siblings, 1 reply; 3+ messages in thread
From: Rusty Russell @ 2008-03-02 21:50 UTC (permalink / raw)
  To: Dmitry Adamushko
  Cc: Andrew Morton, linux-kernel, Nick Piggin, Ingo Molnar,
	Paul E. McKenney, Peter Zijlstra, Andy Whitcroft

On Thursday 21 February 2008 08:36:30 Dmitry Adamushko wrote:
> From: Dmitry Adamushko <dmitry.adamushko@gmail.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.

I always believed that wake_up_process() implies a write barrier.  It's pretty 
common to set something up then wake the intended recipient.

So I think this patch is overkill, but I'm happy to be corrected.

Thanks!
Rusty.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop()
  2008-03-02 21:50 ` Rusty Russell
@ 2008-03-02 22:28   ` Dmitry Adamushko
  0 siblings, 0 replies; 3+ messages in thread
From: Dmitry Adamushko @ 2008-03-02 22:28 UTC (permalink / raw)
  To: Rusty Russell
  Cc: Andrew Morton, linux-kernel, Nick Piggin, Ingo Molnar,
	Paul E. McKenney, Peter Zijlstra, Andy Whitcroft

On 02/03/2008, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Thursday 21 February 2008 08:36:30 Dmitry Adamushko wrote:
>  > From: Dmitry Adamushko <dmitry.adamushko@gmail.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.
>
>
> I always believed that wake_up_process() implies a write barrier.  It's pretty
>  common to set something up then wake the intended recipient.

No, it didn't imply a write mb. Moreover, the situation I tried to
address required a full mb (write vs. read ops. synchronization).

Please take a look at the discussion here http://lkml.org/lkml/2008/2/23/238

and here is a more detailed description of the problem :
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/44c45685680585fc/e58785df0eeee6f8?lnk=raot

>
>  So I think this patch is overkill, but I'm happy to be corrected.

We ended up adding an explicit smp_wmb() (a patch by Linus) to the
very beginning of try_to_wake_up(). Combined with the following
spin_lock() it acts as a 'full' mb for write vs. read ('read' takes
place inside try_to_wake_up()) and that's exactly what we need here.

The 1st link mentioned above may provide more details for interested readers.

So yes, now that we have got smp_wmb() in try_to_wake_up() this patch
is redundant.


>
>  Thanks!
>
> Rusty.
>


-- 
Best regards,
Dmitry Adamushko

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-03-02 22:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-20 21:36 [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop() Dmitry Adamushko
2008-03-02 21:50 ` Rusty Russell
2008-03-02 22:28   ` Dmitry Adamushko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).