1. 28 Jul, 2016 9 commits
  2. 27 Jul, 2016 1 commit
    • Oleg Nesterov's avatar
      stop_machine: Touch_nmi_watchdog() after MULTI_STOP_PREPARE · ce4f06dc
      Oleg Nesterov authored
      Suppose that stop_machine(fn) hangs because fn() hangs. In this case NMI
      hard-lockup can be triggered on another CPU which does nothing wrong and
      the trace from nmi_panic() won't help to investigate the problem.
      
      And this change "fixes" the problem we (seem to) hit in practice.
      
       - stop_two_cpus(0, 1) races with show_state_filter() running on CPU_0.
      
       - CPU_1 already spins in MULTI_STOP_PREPARE state, it detects the soft
         lockup and tries to report the problem.
      
       - show_state_filter() enables preemption, CPU_0 calls multi_cpu_stop()
         which goes to MULTI_STOP_DISABLE_IRQ state and disables interrupts.
      
       - CPU_1 spends more than 10 seconds trying to flush the log buffer to
         the slow serial console.
      
       - NMI interrupt on CPU_0 (which now waits for CPU_1) calls nmi_panic().
      Reported-by: default avatarWang Shu <shuwang@redhat.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Anderson <anderson@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tejun Heo <tj@kernel.org>
      Link: http://lkml.kernel.org/r/20160726185736.GB4088@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ce4f06dc
  3. 26 Jul, 2016 3 commits
  4. 25 Jul, 2016 2 commits
    • Sargun Dhillon's avatar
      bpf: Add bpf_probe_write_user BPF helper to be called in tracers · 96ae5227
      Sargun Dhillon authored
      This allows user memory to be written to during the course of a kprobe.
      It shouldn't be used to implement any kind of security mechanism
      because of TOC-TOU attacks, but rather to debug, divert, and
      manipulate execution of semi-cooperative processes.
      
      Although it uses probe_kernel_write, we limit the address space
      the probe can write into by checking the space with access_ok.
      We do this as opposed to calling copy_to_user directly, in order
      to avoid sleeping. In addition we ensure the threads's current fs
      / segment is USER_DS and the thread isn't exiting nor a kernel thread.
      
      Given this feature is meant for experiments, and it has a risk of
      crashing the system, and running programs, we print a warning on
      when a proglet that attempts to use this helper is installed,
      along with the pid and process name.
      Signed-off-by: default avatarSargun Dhillon <sargun@sargun.me>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96ae5227
    • Daniel Borkmann's avatar
      bpf, events: fix offset in skb copy handler · aa7145c1
      Daniel Borkmann authored
      This patch fixes the __output_custom() routine we currently use with
      bpf_skb_copy(). I missed that when len is larger than the size of the
      current handle, we can issue multiple invocations of copy_func, and
      __output_custom() advances destination but also source buffer by the
      written amount of bytes. When we have __output_custom(), this is actually
      wrong since in that case the source buffer points to a non-linear object,
      in our case an skb, which the copy_func helper is supposed to walk.
      Therefore, since this is non-linear we thus need to pass the offset into
      the helper, so that copy_func can use it for extracting the data from
      the source object.
      
      Therefore, adjust the callback signatures properly and pass offset
      into the skb_header_pointer() invoked from bpf_skb_copy() callback. The
      __DEFINE_OUTPUT_COPY_BODY() is adjusted to accommodate for two things:
      i) to pass in whether we should advance source buffer or not; this is
      a compile-time constant condition, ii) to pass in the offset for
      __output_custom(), which we do with help of __VA_ARGS__, so everything
      can stay inlined as is currently. Both changes allow for adapting the
      __output_* fast-path helpers w/o extra overhead.
      
      Fixes: 555c8a86 ("bpf: avoid stack copy and use skb ctx for event output")
      Fixes: 7e3f977e ("perf, events: add non-linear data support for raw records")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aa7145c1
  5. 22 Jul, 2016 1 commit
    • Chen Yu's avatar
      PM / hibernate: Introduce test_resume mode for hibernation · fe12c00d
      Chen Yu authored
      test_resume mode is to verify if the snapshot data
      written to swap device can be successfully restored
      to memory. It is useful to ease the debugging process
      on hibernation, since this mode can not only bypass
      the BIOSes/bootloader, but also the system re-initialization.
      
      To avoid the risk to break the filesystm on persistent storage,
      this patch resumes the image with tasks frozen.
      
      For example:
      echo test_resume > /sys/power/disk
      echo disk > /sys/power/state
      
      [  187.306470] PM: Image saving progress:  70%
      [  187.395298] PM: Image saving progress:  80%
      [  187.476697] PM: Image saving progress:  90%
      [  187.554641] PM: Image saving done.
      [  187.558896] PM: Wrote 594600 kbytes in 0.90 seconds (660.66 MB/s)
      [  187.566000] PM: S|
      [  187.589742] PM: Basic memory bitmaps freed
      [  187.594694] PM: Checking hibernation image
      [  187.599865] PM: Image signature found, resuming
      [  187.605209] PM: Loading hibernation image.
      [  187.665753] PM: Basic memory bitmaps created
      [  187.691397] PM: Using 3 thread(s) for decompression.
      [  187.691397] PM: Loading and decompressing image data (148650 pages)...
      [  187.889719] PM: Image loading progress:   0%
      [  188.100452] PM: Image loading progress:  10%
      [  188.244781] PM: Image loading progress:  20%
      [  189.057305] PM: Image loading done.
      [  189.068793] PM: Image successfully loaded
      Suggested-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fe12c00d
  6. 21 Jul, 2016 1 commit
    • Steve Muckle's avatar
      cpufreq: schedutil: map raw required frequency to driver frequency · 5cbea469
      Steve Muckle authored
      The slow-path frequency transition path is relatively expensive as it
      requires waking up a thread to do work. Should support be added for
      remote CPU cpufreq updates that is also expensive since it requires an
      IPI. These activities should be avoided if they are not necessary.
      
      To that end, calculate the actual driver-supported frequency required by
      the new utilization value in schedutil by using the recently added
      cpufreq_driver_resolve_freq API. If it is the same as the previously
      requested driver frequency then there is no need to continue with the
      update assuming the cpu frequency limits have not changed. This will
      have additional benefits should the semantics of the rate limit be
      changed to apply solely to frequency transitions rather than to
      frequency calculations in schedutil.
      
      The last raw required frequency is cached. This allows the driver
      frequency lookup to be skipped in the event that the new raw required
      frequency matches the last one, assuming a frequency update has not been
      forced due to limits changing (indicated by a next_freq value of
      UINT_MAX, see sugov_should_update_freq).
      Signed-off-by: default avatarSteve Muckle <smuckle@linaro.org>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5cbea469
  7. 20 Jul, 2016 1 commit
    • Paul Moore's avatar
      audit: fix a double fetch in audit_log_single_execve_arg() · 43761473
      Paul Moore authored
      There is a double fetch problem in audit_log_single_execve_arg()
      where we first check the execve(2) argumnets for any "bad" characters
      which would require hex encoding and then re-fetch the arguments for
      logging in the audit record[1].  Of course this leaves a window of
      opportunity for an unsavory application to munge with the data.
      
      This patch reworks things by only fetching the argument data once[2]
      into a buffer where it is scanned and logged into the audit
      records(s).  In addition to fixing the double fetch, this patch
      improves on the original code in a few other ways: better handling
      of large arguments which require encoding, stricter record length
      checking, and some performance improvements (completely unverified,
      but we got rid of some strlen() calls, that's got to be a good
      thing).
      
      As part of the development of this patch, I've also created a basic
      regression test for the audit-testsuite, the test can be tracked on
      GitHub at the following link:
      
       * https://github.com/linux-audit/audit-testsuite/issues/25
      
      [1] If you pay careful attention, there is actually a triple fetch
      problem due to a strnlen_user() call at the top of the function.
      
      [2] This is a tiny white lie, we do make a call to strnlen_user()
      prior to fetching the argument data.  I don't like it, but due to the
      way the audit record is structured we really have no choice unless we
      copy the entire argument at once (which would require a rather
      wasteful allocation).  The good news is that with this patch the
      kernel no longer relies on this strnlen_user() value for anything
      beyond recording it in the log, we also update it with a trustworthy
      value whenever possible.
      Reported-by: default avatarPengfei Wang <wpengfeinudt@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      43761473
  8. 19 Jul, 2016 8 commits
  9. 16 Jul, 2016 1 commit
  10. 15 Jul, 2016 12 commits
    • Daniel Borkmann's avatar
      bpf: avoid stack copy and use skb ctx for event output · 555c8a86
      Daniel Borkmann authored
      This work addresses a couple of issues bpf_skb_event_output()
      helper currently has: i) We need two copies instead of just a
      single one for the skb data when it should be part of a sample.
      The data can be non-linear and thus needs to be extracted via
      bpf_skb_load_bytes() helper first, and then copied once again
      into the ring buffer slot. ii) Since bpf_skb_load_bytes()
      currently needs to be used first, the helper needs to see a
      constant size on the passed stack buffer to make sure BPF
      verifier can do sanity checks on it during verification time.
      Thus, just passing skb->len (or any other non-constant value)
      wouldn't work, but changing bpf_skb_load_bytes() is also not
      the proper solution, since the two copies are generally still
      needed. iii) bpf_skb_load_bytes() is just for rather small
      buffers like headers, since they need to sit on the limited
      BPF stack anyway. Instead of working around in bpf_skb_load_bytes(),
      this work improves the bpf_skb_event_output() helper to address
      all 3 at once.
      
      We can make use of the passed in skb context that we have in
      the helper anyway, and use some of the reserved flag bits as
      a length argument. The helper will use the new __output_custom()
      facility from perf side with bpf_skb_copy() as callback helper
      to walk and extract the data. It will pass the data for setup
      to bpf_event_output(), which generates and pushes the raw record
      with an additional frag part. The linear data used in the first
      frag of the record serves as programmatically defined meta data
      passed along with the appended sample.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      555c8a86
    • Daniel Borkmann's avatar
      bpf, perf: split bpf_perf_event_output · 8e7a3920
      Daniel Borkmann authored
      Split the bpf_perf_event_output() helper as a preparation into
      two parts. The new bpf_perf_event_output() will prepare the raw
      record itself and test for unknown flags from BPF trace context,
      where the __bpf_perf_event_output() does the core work. The
      latter will be reused later on from bpf_event_output() directly.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e7a3920
    • Daniel Borkmann's avatar
      perf, events: add non-linear data support for raw records · 7e3f977e
      Daniel Borkmann authored
      This patch adds support for non-linear data on raw records. It
      extends raw records to have one or multiple fragments that will
      be written linearly into the ring slot, where each fragment can
      optionally have a custom callback handler to walk and extract
      complex, possibly non-linear data.
      
      If a callback handler is provided for a fragment, then the new
      __output_custom() will be used instead of __output_copy() for
      the perf_output_sample() part. perf_prepare_sample() does all
      the size calculation only once, so perf_output_sample() doesn't
      need to redo the same work anymore, meaning real_size and padding
      will be cached in the raw record. The raw record becomes 32 bytes
      in size without holes; to not increase it further and to avoid
      doing unnecessary recalculations in fast-path, we can reuse
      next pointer of the last fragment, idea here is borrowed from
      ZERO_OR_NULL_PTR(), which should keep the perf_output_sample()
      path for PERF_SAMPLE_RAW minimal.
      
      This facility is needed for BPF's event output helper as a first
      user that will, in a follow-up, add an additional perf_raw_frag
      to its perf_raw_record in order to be able to more efficiently
      dump skb context after a linear head meta data related to it.
      skbs can be non-linear and thus need a custom output function to
      dump buffers. Currently, the skb data needs to be copied twice;
      with the help of __output_custom() this work only needs to be
      done once. Future users could be things like XDP/BPF programs
      that work on different context though and would thus also have
      a different callback function.
      
      The few users of raw records are adapted to initialize their frag
      data from the raw record itself, no change in behavior for them.
      The code is based upon a PoC diff provided by Peter Zijlstra [1].
      
        [1] http://thread.gmane.org/gmane.linux.network/421294Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e3f977e
    • Rafael J. Wysocki's avatar
      x86 / hibernate: Use hlt_play_dead() when resuming from hibernation · 406f992e
      Rafael J. Wysocki authored
      On Intel hardware, native_play_dead() uses mwait_play_dead() by
      default and only falls back to the other methods if that fails.
      That also happens during resume from hibernation, when the restore
      (boot) kernel runs disable_nonboot_cpus() to take all of the CPUs
      except for the boot one offline.
      
      However, that is problematic, because the address passed to
      __monitor() in mwait_play_dead() is likely to be written to in the
      last phase of hibernate image restoration and that causes the "dead"
      CPU to start executing instructions again.  Unfortunately, the page
      containing the address in that CPU's instruction pointer may not be
      valid any more at that point.
      
      First, that page may have been overwritten with image kernel memory
      contents already, so the instructions the CPU attempts to execute may
      simply be invalid.  Second, the page tables previously used by that
      CPU may have been overwritten by image kernel memory contents, so the
      address in its instruction pointer is impossible to resolve then.
      
      A report from Varun Koyyalagunta and investigation carried out by
      Chen Yu show that the latter sometimes happens in practice.
      
      To prevent it from happening, temporarily change the smp_ops.play_dead
      pointer during resume from hibernation so that it points to a special
      "play dead" routine which uses hlt_play_dead() and avoids the
      inadvertent "revivals" of "dead" CPUs this way.
      
      A slightly unpleasant consequence of this change is that if the
      system is hibernated with one or more CPUs offline, it will generally
      draw more power after resume than it did before hibernation, because
      the physical state entered by CPUs via hlt_play_dead() is higher-power
      than the mwait_play_dead() one in the majority of cases.  It is
      possible to work around this, but it is unclear how much of a problem
      that's going to be in practice, so the workaround will be implemented
      later if it turns out to be necessary.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=106371Reported-by: default avatarVarun Koyyalagunta <cpudebug@centtech.com>
      Original-by: default avatarChen Yu <yu.c.chen@intel.com>
      Tested-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      406f992e
    • Eric W. Biederman's avatar
      cgroupns: Only allow creation of hierarchies in the initial cgroup namespace · 726a4994
      Eric W. Biederman authored
      Unprivileged users can't use hierarchies if they create them as they do not
      have privilieges to the root directory.
      
      Which means the only thing a hiearchy created by an unprivileged user
      is good for is expanding the number of cgroup links in every css_set,
      which is a DOS attack.
      
      We could allow hierarchies to be created in namespaces in the initial
      user namespace.  Unfortunately there is only a single namespace for
      the names of heirarchies, so that is likely to create more confusion
      than not.
      
      So do the simple thing and restrict hiearchy creation to the initial
      cgroup namespace.
      
      Cc: stable@vger.kernel.org
      Fixes: a79a908f ("cgroup: introduce cgroup namespaces")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      726a4994
    • Eric W. Biederman's avatar
      cgroupns: Close race between cgroup_post_fork and copy_cgroup_ns · eedd0f4c
      Eric W. Biederman authored
      In most code paths involving cgroup migration cgroup_threadgroup_rwsem
      is taken.  There are two exceptions:
      
      - remove_tasks_in_empty_cpuset calls cgroup_transfer_tasks
      - vhost_attach_cgroups_work calls cgroup_attach_task_all
      
      With cgroup_threadgroup_rwsem held it is guaranteed that cgroup_post_fork
      and copy_cgroup_ns will reference the same css_set from the process calling
      fork.
      
      Without such an interlock there process after fork could reference one
      css_set from it's new cgroup namespace and another css_set from
      task->cgroups, which semantically is nonsensical.
      
      Cc: stable@vger.kernel.org
      Fixes: a79a908f ("cgroup: introduce cgroup namespaces")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      eedd0f4c
    • Eric W. Biederman's avatar
      cgroupns: Fix the locking in copy_cgroup_ns · 7bd88308
      Eric W. Biederman authored
      If "clone(CLONE_NEWCGROUP...)" is called it results in a nice lockdep
      valid splat.
      
      In __cgroup_proc_write the lock ordering is:
           cgroup_mutex -- through cgroup_kn_lock_live
           cgroup_threadgroup_rwsem
      
      In copy_process the guts of clone the lock ordering is:
           cgroup_threadgroup_rwsem -- through threadgroup_change_begin
           cgroup_mutex -- through copy_namespaces -- copy_cgroup_ns
      
      lockdep reports some a different call chains for the first ordering of
      cgroup_mutex and cgroup_threadgroup_rwsem but it is harder to trace.
      This is most definitely deadlock potential under the right
      circumstances.
      
      Fix this by by skipping the cgroup_mutex and making the locking in
      copy_cgroup_ns mirror the locking in cgroup_post_fork which also runs
      during fork under the cgroup_threadgroup_rwsem.
      
      Cc: stable@vger.kernel.org
      Fixes: a79a908f ("cgroup: introduce cgroup namespaces")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      7bd88308
    • Thomas Gleixner's avatar
      rcu: Convert rcutree to hotplug state machine · 4df83742
      Thomas Gleixner authored
      Straight forward conversion to the state machine. Though the question arises
      whether this needs really all these state transitions to work.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAnna-Maria Gleixner <anna-maria@linutronix.de>
      Reviewed-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: rt@linutronix.de
      Link: http://lkml.kernel.org/r/20160713153337.982013161@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4df83742
    • Richard Weinberger's avatar
      smp/cfd: Convert core to hotplug state machine · 31487f83
      Richard Weinberger authored
      Install the callbacks via the state machine. They are installed at runtime so
      smpcfd_prepare_cpu() needs to be invoked by the boot-CPU.
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      [ Added the dropped CPU dying case back in. ]
      Signed-off-by: default avatarRichard Cochran <rcochran@linutronix.de>
      Signed-off-by: default avatarAnna-Maria Gleixner <anna-maria@linutronix.de>
      Reviewed-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Davidlohr Bueso <dave@stgolabs>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: rt@linutronix.de
      Link: http://lkml.kernel.org/r/20160713153337.818376366@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      31487f83
    • Sebastian Andrzej Siewior's avatar
      profile: Convert to hotplug state machine · e722d8da
      Sebastian Andrzej Siewior authored
      Install the callbacks via the state machine and let the core invoke
      the callbacks on the already online CPUs. A lot of code is removed because
      the for-loop is used and create_hash_tables() is removed since its purpose
      is covered by the startup / teardown hooks.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarAnna-Maria Gleixner <anna-maria@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: rt@linutronix.de
      Link: http://lkml.kernel.org/r/20160713153337.649867675@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e722d8da
    • Richard Cochran's avatar
      timers/core: Convert to hotplug state machine · 24f73b99
      Richard Cochran authored
      When tearing down, call timers_dead_cpu() before notify_dead().
      There is a hidden dependency between:
      
       - timers
       - block multiqueue
       - rcutree
      
      If timers_dead_cpu() comes later than blk_mq_queue_reinit_notify()
      that latter function causes a RCU stall.
      Signed-off-by: default avatarRichard Cochran <rcochran@linutronix.de>
      Signed-off-by: default avatarAnna-Maria Gleixner <anna-maria@linutronix.de>
      Reviewed-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: rt@linutronix.de
      Link: http://lkml.kernel.org/r/20160713153337.566790058@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      24f73b99
    • Thomas Gleixner's avatar
      hrtimer: Convert to hotplug state machine · 27590dc1
      Thomas Gleixner authored
      Split out the clockevents callbacks instead of piggybacking them on
      hrtimers.
      
      This gets rid of a POST_DEAD user. See commit:
      
        54e88fad ("sched: Make sure timers have migrated before killing the migration_thread")
      
      We just move the callback state to the proper place in the state machine.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAnna-Maria Gleixner <anna-maria@linutronix.de>
      Reviewed-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: rt@linutronix.de
      Link: http://lkml.kernel.org/r/20160713153337.485419196@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      27590dc1
  11. 14 Jul, 2016 1 commit