linux-kernel - Re: [PATCH, RFC] kthread: (possibly) a missing memory barrier in 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b647ffbd0802190511u44fc8353wa4cbb290bcf371ae@mail.gmail.com>
Date:	Tue, 19 Feb 2008 14:11:30 +0100
From:	"Dmitry Adamushko" <dmitry.adamushko@...il.com>
To:	"Andy Whitcroft" <apw@...dowen.org>
Cc:	linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...e.hu>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Rusty Russel" <rusty@...tcorp.com.au>
Subject: Re: [PATCH, RFC] kthread: (possibly) a missing memory barrier in kthread_stop()

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