login
Login
/
Register
Search
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
February
»
19
Re: [PATCH, RFC] kthread: (possibly) a missing memory barrier in kthread_stop()
view
thread
!MAILaRCHIVE_VOTE_RePLACE
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From:
Nick Piggin <nickpiggin@...>
To: Dmitry Adamushko <dmitry.adamushko@...>
Cc: <linux-kernel@...>, Ingo Molnar <mingo@...>, Andrew Morton <akpm@...>, Peter Zijlstra <a.p.zijlstra@...>, Rusty Russel <rusty@...>
Subject:
Re: [PATCH, RFC] kthread: (possibly) a missing memory barrier in kthread_stop()
Date: Tuesday, February 19, 2008 - 2:44 am
On Tuesday 19 February 2008 10:03, Dmitry Adamushko wrote:
quoted text
> Hi, > > > [ description ] > > Subject: kthread: add a memory barrier to kthread_stop() > > 'kthread' threads do a check in the following order: > - set_current_state(TASK_INTERRUPTIBLE); > - kthread_should_stop(); > > and set_current_state() implies an smp_mb(). > > on another side (kthread_stop), wake_up_process() does not seem to > guarantee a full mb. > > And 'kthread_stop_info.k' must be visible before wake_up_process() > checks for/modifies a state of the 'kthread' task. > > (the patch is at the end of the message) > > > [ more detailed description ] > > the current code might well be safe in case a to-be-stopped 'kthread' > task is _not_ running on another CPU at the moment when kthread_stop() > is called (in this case, 'rq->lock' will act as a kind of synch. > point/barrier). > > Another case is as follows: > > CPU#0: > > ... > while (kthread_should_stop()) { > > if (condition) > schedule(); > > /* ... do something useful ... */ <--- EIP > > set_current_state(TASK_INTERRUPTIBLE); > } > > so a 'kthread' task is about to call > set_current_state(TASK_INTERRUPTIBLE) ... > > > (in the mean time) > > CPU#1: > > kthread_stop() > > -> kthread_stop_info.k = k (*) > -> wake_up_process() > > wake_up_process() looks like: > > (try_to_wake_up) > > IRQ_OFF > LOCK > > old_state = p->state; > if (!(old_state & state)) (**) > goto out; > > ... > > UNLOCK > IRQ_ON > > > let's suppose (*) and (**) are reordered > (according to Documentation/memory-barriers.txt, neither IRQ_OFF nor > LOCK may prevent it from happening). > > - the state is TASK_RUNNING, so we are about to return. > > - CPU#1 is about to execute (*) (it's guaranteed to be done before > spin_unlock(&rq->lock) at the end of try_to_wake_up()) > > > (in the mean time) > > CPU#0: > > - set_current_state(TASK_INTERRUPTIBLE); > - kthread_should_stop(); > > here, kthread_stop_info.k is not yet visible > > - schedule() > > ... > > we missed a 'kthread_stop' event. > > hum?
Looks like you are correct to me.
quoted text
> TIA, > > --- > > From: Dmitry Adamushko <dmitry.adamushko@gmail.com> > Subject: kthread: add a memory barrier to kthread_stop() > > 'kthread' threads do a check in the following order: > - set_current_state(TASK_INTERRUPTIBLE); > - kthread_should_stop(); > > and set_current_state() implies an smp_mb(). > > on another side (kthread_stop), wake_up_process() is not guaranteed to > act as a full mb. > > 'kthread_stop_info.k' must be visible before wake_up_process() checks > for/modifies a state of the 'kthread' task. > > > Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com> > > > diff --git a/kernel/kthread.c b/kernel/kthread.c > index 0ac8878..5167110 100644 > --- a/kernel/kthread.c > +++ b/kernel/kthread.c > @@ -211,6 +211,10 @@ int kthread_stop(struct task_struct *k) > > /* Now set kthread_should_stop() to true, and wake it up. */ > kthread_stop_info.k = k; > + > + /* The previous store operation must not get ahead of the wakeup. */ > + smp_mb(); > + > wake_up_process(k); > put_task_struct(k); > > > > --
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
[PATCH, RFC] kthread: (possibly) a missing memory barrier in...
, Dmitry Adamushko
, (Mon Feb 18, 7:03 pm)
Re: [PATCH, RFC] kthread: (possibly) a missing memory barrie...
, Andy Whitcroft
, (Tue Feb 19, 9:00 am)
Re: [PATCH, RFC] kthread: (possibly) a missing memory barrie...
, Dmitry Adamushko
, (Tue Feb 19, 9:11 am)
Re: [PATCH, RFC] kthread: (possibly) a missing memory barrie...
, Nick Piggin
, (Tue Feb 19, 2:44 am)
Re: [PATCH, RFC] kthread: (possibly) a missing memory barrie...
, Peter Zijlstra
, (Tue Feb 19, 5:24 am)
Re: [PATCH, RFC] kthread: (possibly) a missing memory barrie...
, Dmitry Adamushko
, (Tue Feb 19, 9:41 am)
Re: [PATCH, RFC] kthread: (possibly) a missing memory barrie...
, Dmitry Adamushko
, (Tue Feb 19, 6:52 pm)
Re: [PATCH, RFC] kthread: (possibly) a missing memory barrie...
, Dmitry Adamushko
, (Tue Feb 19, 5:53 am)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Greg KH
[GIT PATCH] driver core patches against 2.6.24
Andi Kleen
[PATCH x86] [0/16] Various i386/x86-64 changes
Vladislav Bolkhovitin
Re: Integration of SCST in the mainstream Linux kernel
Tarkan Erimer
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
openbsd-misc
:
git
:
linux-netdev
:
Gerrit Renker
[PATCH 0/37] dccp: Feature negotiation - last call for comments
Jarek Poplawski
Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock().
Natalie Protasevich
[BUG] New Kernel Bugs
Arjan van de Ven
Re: [GIT]: Networking
Colocation donated by:
Who's online
There are currently
1 user
and
741 guests
online.
Online users
garytall101
Syndicate