[PATCH 1/2] kthread: add a missing memory barrier to kthread_stop() - Kernel

This is a discussion on [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop() - Kernel ; From: Dmitry Adamushko 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() ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop()

  1. [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop()

    From: Dmitry Adamushko
    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


    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);



    --
    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/

  2. Re: [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop()

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

  3. Re: [PATCH 1/2] kthread: add a missing memory barrier to kthread_stop()

    On 02/03/2008, Rusty Russell wrote:
    > On Thursday 21 February 2008 08:36:30 Dmitry Adamushko wrote:
    > > From: Dmitry Adamushko
    > > 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.li...ee6f8?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
    --
    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/

+ Reply to Thread