On 19/02/2008, Andy Whitcroft <[EMAIL PROTECTED]> wrote: > [ ... ] > > > 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); > > The rules as written do seem to support your theory. The CPU has every > right to delay the .k = k as late as the UNLOCK operation. > > On the read-side there is a full barrier implied by the > set_current_state(TASK_INTERRUPTIBLE), however this synchronises us with > the current global state, which may well not have the updated version > of .k.
yes. > > That seems to imply that a write memory barrier would be sufficient to > cover this. > > So three comments. First, should this not be an smp_wmb. No. We also need to be sure that ".k = k" is updated by the moment we check for a state of the task in try_to_wake_up(), so that's write vs. read ops. The point is that a 'kthread' loop does : (1) set TASK_INTERRUPTIBLE (2) check for .k == k and kthread_stop() must do it in the _reverse_ order: (1) .k = k (2) check for a task state and wakeup if necessary. Only this way we ensure that a wakeup is not lost. > Second, this > memory barrier is paired with the barrier in > set_current_state(TASK_INTERRUPTIBLE) and that probabally should be > documented as part of this patch. Finally, I think the comment as is is > hard to understand I got the sense of it backwards on first reading; > perhaps something like this: > > /* > * Ensure kthread_stop_info.k is visible before wakeup, paired > * with barrier in set_current_state(). > */ Yes, I'll try to come up with a better description. > > -apw > -- Best regards, Dmitry Adamushko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
