27 Feb, 2013

1 commit

  • commit 14e568e78 (stop_machine: Use smpboot threads) introduced the
    following regression:

    Before this commit the stopper enabled bit was set in the online
    notifier.

    CPU0 CPU1
    cpu_up
    cpu online
    hotplug_notifier(ONLINE)
    stopper(CPU1)->enabled = true;
    ...
    stop_machine()

    The conversion to smpboot threads moved the enablement to the wakeup
    path of the parked thread. The majority of users seem to have the
    following working order:

    CPU0 CPU1
    cpu_up
    cpu online
    unpark_threads()
    wakeup(stopper[CPU1])
    ....
    stopper thread runs
    stopper(CPU1)->enabled = true;
    stop_machine()

    But Konrad and Sander have observed:

    CPU0 CPU1
    cpu_up
    cpu online
    unpark_threads()
    wakeup(stopper[CPU1])
    ....
    stop_machine()
    stopper thread runs
    stopper(CPU1)->enabled = true;

    Now the stop machinery kicks CPU0 into the stop loop, where it gets
    stuck forever because the queue code saw stopper(CPU1)->enabled ==
    false, so CPU0 waits for CPU1 to enter stomp_machine, but the CPU1
    stopper work got discarded due to enabled == false.

    Add a pre_unpark function to the smpboot thread descriptor and call it
    before waking the thread.

    This fixes the problem at hand, but the stop_machine code should be
    more robust. The stopper->enabled flag smells fishy at best.

    Thanks to Konrad for going through a loop of debug patches and
    providing the information to decode this issue.

    Reported-and-tested-by: Konrad Rzeszutek Wilk
    Reported-and-tested-by: Sander Eikelenboom
    Cc: Srivatsa S. Bhat
    Cc: Rusty Russell
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1302261843240.22263@ionos
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

14 Feb, 2013

1 commit

  • The stop machine threads are still killed when a cpu goes offline. The
    reason is that the thread is used to bring the cpu down, so it can't
    be parked along with the other per cpu threads.

    Allow a per cpu thread to be excluded from automatic parking, so it
    can park itself once it's done

    Add a create callback function as well.

    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: Rusty Russell
    Cc: Paul McKenney
    Cc: Srivatsa S. Bhat
    Cc: Arjan van de Veen
    Cc: Paul Turner
    Cc: Richard Weinberger
    Cc: Magnus Damm
    Link: http://lkml.kernel.org/r/20130131120741.553993267@linutronix.de
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

13 Aug, 2012

1 commit

  • Provide a generic interface for setting up and tearing down percpu
    threads.

    On registration the threads for already online cpus are created and
    started. On deregistration (modules) the threads are stoppped.

    During hotplug operations the threads are created, started, parked and
    unparked. The datastructure for registration provides a pointer to
    percpu storage space and optional setup, cleanup, park, unpark
    functions. These functions are called when the thread state changes.

    Each implementation has to provide a function which is queried and
    returns whether the thread should run and the thread function itself.

    The core code handles all state transitions and avoids duplicated code
    in the call sites.

    [ paulmck: Preemption leak fix ]

    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra
    Reviewed-by: Srivatsa S. Bhat
    Cc: Rusty Russell
    Reviewed-by: Paul E. McKenney
    Cc: Namhyung Kim
    Link: http://lkml.kernel.org/r/20120716103948.352501068@linutronix.de
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner