Re: [PATCH, RFC] kthread: (possibly) a missing memory barrier in kthread_stop()

["Dmitry Adamushko" <dmitry.adamushko@gmail.com>]

On 19/02/2008, Andy Whitcroft <apw@shadowen.org> 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