13 Dec, 2015

1 commit

  • Currently the full stop_machine() routine is only enabled on SMP if
    module unloading is enabled, or if the CPUs are hotpluggable. This
    leads to configurations where stop_machine() is broken as it will then
    only run the callback on the local CPU with irqs disabled, and not stop
    the other CPUs or run the callback on them.

    For example, this breaks MTRR setup on x86 in certain configs since
    ea8596bb2d8d379 ("kprobes/x86: Remove unused text_poke_smp() and
    text_poke_smp_batch() functions") as the MTRR is only established on the
    boot CPU.

    This patch removes the Kconfig option for STOP_MACHINE and uses the SMP
    and HOTPLUG_CPU config options to compile the correct stop_machine() for
    the architecture, removing the false dependency on MODULE_UNLOAD in the
    process.

    Link: https://lkml.org/lkml/2014/10/8/124
    References: https://bugs.freedesktop.org/show_bug.cgi?id=84794
    Signed-off-by: Chris Wilson
    Acked-by: Ingo Molnar
    Cc: "Paul E. McKenney"
    Cc: Pranith Kumar
    Cc: Michal Hocko
    Cc: Vladimir Davydov
    Cc: Johannes Weiner
    Cc: H. Peter Anvin
    Cc: Tejun Heo
    Cc: Iulia Manda
    Cc: Andy Lutomirski
    Cc: Rusty Russell
    Cc: Peter Zijlstra
    Cc: Chuck Ebbert
    Cc: Oleg Nesterov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chris Wilson
     

20 Oct, 2015

2 commits

  • 1. Change smpboot_unpark_thread() to check ->selfparking, just
    like smpboot_park_thread() does.

    2. Introduce stop_machine_unpark() which sets ->enabled and calls
    kthread_unpark().

    3. Change smpboot_thread_call() and cpu_stop_init() to call
    stop_machine_unpark() by hand.

    This way:

    - IMO the ->selfparking logic becomes more consistent.

    - We can kill the smp_hotplug_thread->pre_unpark() method.

    - We can easily unpark the stopper thread earlier. Say, we
    can move stop_machine_unpark() from smpboot_thread_call()
    to sched_cpu_active() as Peter suggests.

    Signed-off-by: Oleg Nesterov
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Andrew Morton
    Cc: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Paul E. McKenney
    Cc: Peter Zijlstra
    Cc: Rik van Riel
    Cc: Tejun Heo
    Cc: Thomas Gleixner
    Cc: heiko.carstens@de.ibm.com
    Link: http://lkml.kernel.org/r/20151009160049.GA10166@redhat.com
    Signed-off-by: Ingo Molnar

    Oleg Nesterov
     
  • cpu_stop_queue_work() checks stopper->enabled before it queues the
    work, but ->enabled == T can only guarantee cpu_stop_signal_done()
    if we race with cpu_down().

    This is not enough for stop_two_cpus() or stop_machine(), they will
    deadlock if multi_cpu_stop() won't be called by one of the target
    CPU's. stop_machine/stop_cpus are fine, they rely on stop_cpus_mutex.
    But stop_two_cpus() has to check cpu_active() to avoid the same race
    with hotplug, and this check is very unobvious and probably not even
    correct if we race with cpu_up().

    Change cpu_down() pass to clear ->enabled before cpu_stopper_thread()
    flushes the pending ->works and returns with KTHREAD_SHOULD_PARK set.

    Note also that smpboot_thread_call() calls cpu_stop_unpark() which
    sets enabled == T at CPU_ONLINE stage, so this CPU can't go away until
    cpu_stopper_thread() is called at least once. This all means that if
    cpu_stop_queue_work() succeeds, we know that work->fn() will be called.

    Signed-off-by: Oleg Nesterov
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Andrew Morton
    Cc: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Paul E. McKenney
    Cc: Peter Zijlstra
    Cc: Rik van Riel
    Cc: Tejun Heo
    Cc: Thomas Gleixner
    Cc: heiko.carstens@de.ibm.com
    Link: http://lkml.kernel.org/r/20151008145131.GA18139@redhat.com
    Signed-off-by: Ingo Molnar

    Oleg Nesterov
     

03 Aug, 2015

2 commits

  • Cosmetic, but 'cpu_stop_fn_t' actually makes the code more readable and
    it doesn't break cscope. And most of the declarations already use it.

    Signed-off-by: Oleg Nesterov
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Tejun Heo
    Cc: Thomas Gleixner
    Cc: dave@stgolabs.net
    Cc: der.herr@hofr.at
    Cc: paulmck@linux.vnet.ibm.com
    Cc: riel@redhat.com
    Cc: viro@ZenIV.linux.org.uk
    Link: http://lkml.kernel.org/r/20150630012955.GA23937@redhat.com
    Signed-off-by: Ingo Molnar

    Oleg Nesterov
     
  • The only caller outside of stop_machine.c is _cpu_down(), it can use
    stop_machine(). get_online_cpus() is fine under cpu_hotplug_begin().

    Signed-off-by: Oleg Nesterov
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Tejun Heo
    Cc: Thomas Gleixner
    Cc: dave@stgolabs.net
    Cc: der.herr@hofr.at
    Cc: paulmck@linux.vnet.ibm.com
    Cc: riel@redhat.com
    Cc: viro@ZenIV.linux.org.uk
    Link: http://lkml.kernel.org/r/20150630012951.GA23934@redhat.com
    Signed-off-by: Ingo Molnar

    Oleg Nesterov
     

09 Oct, 2013

1 commit

  • Introduce stop_two_cpus() in order to allow controlled swapping of two
    tasks. It repurposes the stop_machine() state machine but only stops
    the two cpus which we can do with on-stack structures and avoid
    machine wide synchronization issues.

    The ordering of CPUs is important to avoid deadlocks. If unordered then
    two cpus calling stop_two_cpus on each other simultaneously would attempt
    to queue in the opposite order on each CPU causing an AB-BA style deadlock.
    By always having the lowest number CPU doing the queueing of works, we can
    guarantee that works are always queued in the same order, and deadlocks
    are avoided.

    Signed-off-by: Peter Zijlstra
    [ Implemented deadlock avoidance. ]
    Signed-off-by: Rik van Riel
    Cc: Andrea Arcangeli
    Cc: Johannes Weiner
    Cc: Srikar Dronamraju
    Signed-off-by: Mel Gorman
    Link: http://lkml.kernel.org/r/1381141781-10992-38-git-send-email-mgorman@suse.de
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

29 Mar, 2012

1 commit


01 Nov, 2011

1 commit

  • This will show up on MIPS when we fix all the implicit header presences
    that are because of module.h being everywhere.

    In file included from kernel/trace/ftrace.c:16:
    include/linux/stop_machine.h: In function 'stop_one_cpu':
    include/linux/stop_machine.h:50: error: implicit declaration of function 'smp_processor_id'
    include/linux/stop_machine.h: In function 'stop_cpus':
    include/linux/stop_machine.h:80: error: implicit declaration of function 'raw_smp_processor_id'

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

26 Jul, 2011

1 commit

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (43 commits)
    fs: Merge split strings
    treewide: fix potentially dangerous trailing ';' in #defined values/expressions
    uwb: Fix misspelling of neighbourhood in comment
    net, netfilter: Remove redundant goto in ebt_ulog_packet
    trivial: don't touch files that are removed in the staging tree
    lib/vsprintf: replace link to Draft by final RFC number
    doc: Kconfig: `to be' -> `be'
    doc: Kconfig: Typo: square -> squared
    doc: Konfig: Documentation/power/{pm => apm-acpi}.txt
    drivers/net: static should be at beginning of declaration
    drivers/media: static should be at beginning of declaration
    drivers/i2c: static should be at beginning of declaration
    XTENSA: static should be at beginning of declaration
    SH: static should be at beginning of declaration
    MIPS: static should be at beginning of declaration
    ARM: static should be at beginning of declaration
    rcu: treewide: Do not use rcu_read_lock_held when calling rcu_dereference_check
    Update my e-mail address
    PCIe ASPM: forcedly -> forcibly
    gma500: push through device driver tree
    ...

    Fix up trivial conflicts:
    - arch/arm/mach-ep93xx/dma-m2p.c (deleted)
    - drivers/gpio/gpio-ep93xx.c (renamed and context nearby)
    - drivers/net/r8169.c (just context changes)

    Linus Torvalds
     

28 Jun, 2011

3 commits

  • MTRR rendezvous sequence is not implemened using stop_machine() before, as this
    gets called both from the process context aswell as the cpu online paths
    (where the cpu has not come online and the interrupts are disabled etc).

    Now that we have a new stop_machine_from_inactive_cpu() API, use it for
    rendezvous during mtrr init of a logical processor that is coming online.

    For the rest (runtime MTRR modification, system boot, resume paths), use
    stop_machine() to implement the rendezvous sequence. This will consolidate and
    cleanup the code.

    Signed-off-by: Suresh Siddha
    Link: http://lkml.kernel.org/r/20110623182057.076997177@sbsiddha-MOBL3.sc.intel.com
    Signed-off-by: H. Peter Anvin

    Suresh Siddha
     
  • Currently, mtrr wants stop_machine functionality while a CPU is being
    brought up. As stop_machine() requires the calling CPU to be active,
    mtrr implements its own stop_machine using stop_one_cpu() on each
    online CPU. This doesn't only unnecessarily duplicate complex logic
    but also introduces a possibility of deadlock when it races against
    the generic stop_machine().

    This patch implements stop_machine_from_inactive_cpu() to serve such
    use cases. Its functionality is basically the same as stop_machine();
    however, it should be called from a CPU which isn't active and doesn't
    depend on working scheduling on the calling CPU.

    This is achieved by using busy loops for synchronization and
    open-coding stop_cpus queuing and waiting with direct invocation of
    fn() for local CPU inbetween.

    Signed-off-by: Tejun Heo
    Link: http://lkml.kernel.org/r/20110623182056.982526827@sbsiddha-MOBL3.sc.intel.com
    Signed-off-by: Suresh Siddha
    Cc: Ingo Molnar
    Cc: Andrew Morton
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Signed-off-by: H. Peter Anvin

    Tejun Heo
     
  • MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially
    happen in parallel with another system wide rendezvous using
    stop_machine(). This can lead to deadlock (The order in which
    works are queued can be different on different cpu's. Some cpu's
    will be running the first rendezvous handler and others will be running
    the second rendezvous handler. Each set waiting for the other set to join
    for the system wide rendezvous, leading to a deadlock).

    MTRR rendezvous sequence is not implemented using stop_machine() as this
    gets called both from the process context aswell as the cpu online paths
    (where the cpu has not come online and the interrupts are disabled etc).
    stop_machine() works with only online cpus.

    For now, take the stop_machine mutex in the MTRR rendezvous sequence that
    gets called from an online cpu (here we are in the process context
    and can potentially sleep while taking the mutex). And the MTRR rendezvous
    that gets triggered during cpu online doesn't need to take this stop_machine
    lock (as the stop_machine() already ensures that there is no cpu hotplug
    going on in parallel by doing get_online_cpus())

    TBD: Pursue a cleaner solution of extending the stop_machine()
    infrastructure to handle the case where the calling cpu is
    still not online and use this for MTRR rendezvous sequence.

    fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008

    Reported-by: Vadim Kotelnikov
    Signed-off-by: Suresh Siddha
    Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com
    Cc: stable@kernel.org # 2.6.35+, backport a week or two after this gets more testing in mainline
    Signed-off-by: H. Peter Anvin

    Suresh Siddha
     

20 Jun, 2011

1 commit


31 Mar, 2011

1 commit


14 Oct, 2010

1 commit

  • Define dummy __stop_machine() function even when
    CONFIG_STOP_MACHINE=n. This getcpu-required version of
    stop_machine() will be used from poke_text_smp().

    Signed-off-by: Masami Hiramatsu
    Acked-by: Tejun Heo
    Cc: Rusty Russell
    Cc: Ananth N Mavinakayanahalli
    Cc: 2nddept-manager@sdl.hitachi.co.jp
    Cc: Peter Zijlstra
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Masami Hiramatsu
     

08 May, 2010

1 commit

  • When !CONFIG_SMP, cpu_stop functions weren't defined at all which
    could lead to build failures if UP code uses cpu_stop facility. Add
    dummy cpu_stop implementation for UP. The waiting variants execute
    the work function directly with preempt disabled and
    stop_one_cpu_nowait() schedules a workqueue work.

    Makefile and ifdefs around stop_machine implementation are updated to
    accomodate CONFIG_SMP && !CONFIG_STOP_MACHINE case.

    Signed-off-by: Tejun Heo
    Reported-by: Ingo Molnar

    Tejun Heo
     

07 May, 2010

2 commits

  • Reimplement stop_machine using cpu_stop. As cpu stoppers are
    guaranteed to be available for all online cpus,
    stop_machine_create/destroy() are no longer necessary and removed.

    With resource management and synchronization handled by cpu_stop, the
    new implementation is much simpler. Asking the cpu_stop to execute
    the stop_cpu() state machine on all online cpus with cpu hotplug
    disabled is enough.

    stop_machine itself doesn't need to manage any global resources
    anymore, so all per-instance information is rolled into struct
    stop_machine_data and the mutex and all static data variables are
    removed.

    The previous implementation created and destroyed RT workqueues as
    necessary which made stop_machine() calls highly expensive on very
    large machines. According to Dimitri Sivanich, preventing the dynamic
    creation/destruction makes booting faster more than twice on very
    large machines. cpu_stop resources are preallocated for all online
    cpus and should have the same effect.

    Signed-off-by: Tejun Heo
    Acked-by: Rusty Russell
    Acked-by: Peter Zijlstra
    Cc: Oleg Nesterov
    Cc: Dimitri Sivanich

    Tejun Heo
     
  • Implement a simplistic per-cpu maximum priority cpu monopolization
    mechanism. A non-sleeping callback can be scheduled to run on one or
    multiple cpus with maximum priority monopolozing those cpus. This is
    primarily to replace and unify RT workqueue usage in stop_machine and
    scheduler migration_thread which currently is serving multiple
    purposes.

    Four functions are provided - stop_one_cpu(), stop_one_cpu_nowait(),
    stop_cpus() and try_stop_cpus().

    This is to allow clean sharing of resources among stop_cpu and all the
    migration thread users. One stopper thread per cpu is created which
    is currently named "stopper/CPU". This will eventually replace the
    migration thread and take on its name.

    * This facility was originally named cpuhog and lived in separate
    files but Peter Zijlstra nacked the name and thus got renamed to
    cpu_stop and moved into stop_machine.c.

    * Better reporting of preemption leak as per Peter's suggestion.

    Signed-off-by: Tejun Heo
    Acked-by: Peter Zijlstra
    Cc: Oleg Nesterov
    Cc: Dimitri Sivanich

    Tejun Heo
     

05 Jan, 2009

1 commit

  • Introduce stop_machine_create/destroy. With this interface subsystems
    that need a non-failing stop_machine environment can create the
    stop_machine machine threads before actually calling stop_machine.
    When the threads aren't needed anymore they can be killed with
    stop_machine_destroy again.

    When stop_machine gets called and the threads aren't present they
    will be created and destroyed automatically. This restores the old
    behaviour of stop_machine.

    This patch also converts cpu hotplug to the new interface since it
    is special: cpu_down calls __stop_machine instead of stop_machine.
    However the kstop threads will only be created when stop_machine
    gets called.

    Changing the code so that the threads would be created automatically
    on __stop_machine is currently not possible: when __stop_machine gets
    called we hold cpu_add_remove_lock, which is the same lock that
    create_rt_workqueue would take. So the workqueue needs to be created
    before the cpu hotplug code locks cpu_add_remove_lock.

    Signed-off-by: Heiko Carstens
    Signed-off-by: Rusty Russell

    Heiko Carstens
     

01 Jan, 2009

1 commit

  • Impact: Reduce stack usage, use new cpumask API.

    Mainly changing cpumask_t to 'struct cpumask' and similar simple API
    conversion. Two conversions worth mentioning:

    1) we use cpumask_any_but to avoid a temporary in kernel/softlockup.c,
    2) Use cpumask_var_t in taskstats_user_cmd().

    Signed-off-by: Rusty Russell
    Signed-off-by: Mike Travis
    Cc: Balbir Singh
    Cc: Ingo Molnar

    Rusty Russell
     

25 Aug, 2008

1 commit


28 Jul, 2008

3 commits

  • Instead of a "cpu" arg with magic values NR_CPUS (any cpu) and ~0 (all
    cpus), pass a cpumask_t. Allow NULL for the common case (where we
    don't care which CPU the function is run on): temporary cpumask_t's
    are usually considered bad for stack space.

    This deprecates stop_machine_run, to be removed soon when all the
    callers are dead.

    Signed-off-by: Rusty Russell

    Rusty Russell
     
  • stop_machine creates a kthread which creates kernel threads. We can
    create those threads directly and simplify things a little. Some care
    must be taken with CPU hotunplug, which has special needs, but that code
    seems more robust than it was in the past.

    Signed-off-by: Rusty Russell
    Acked-by: Christian Borntraeger

    Rusty Russell
     
  • -allow stop_mahcine_run() to call a function on all cpus. Calling
    stop_machine_run() with a 'ALL_CPUS' invokes this new behavior.
    stop_machine_run() proceeds as normal until the calling cpu has
    invoked 'fn'. Then, we tell all the other cpus to call 'fn'.

    Signed-off-by: Jason Baron
    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Rusty Russell
    CC: Adrian Bunk
    CC: Andi Kleen
    CC: Alexey Dobriyan
    CC: Christoph Hellwig
    CC: mingo@elte.hu
    CC: akpm@osdl.org

    Jason Baron
     

26 Apr, 2006

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds