1. 14 8月, 2013 6 次提交
    • F
      vtime: Remove a few unneeded generic vtime state checks · 7621d1f8
      Frederic Weisbecker 提交于
      Some generic vtime APIs check if the vtime accounting
      is enabled on the local CPU before doing their work.
      
      Some of these are not needed because all their callers already
      take care of that. Let's remove the checks on these.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      7621d1f8
    • F
      context_tracking: User/kernel broundary cross trace events · 1b6a259a
      Frederic Weisbecker 提交于
      This can be useful to track all kernel/user round trips.
      And it's also helpful to debug the context tracking subsystem.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      1b6a259a
    • F
      context_tracking: Optimize context switch off case with static keys · 73d424f9
      Frederic Weisbecker 提交于
      No need for syscall slowpath if no CPU is full dynticks,
      rather nop this in this case.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      73d424f9
    • F
      context_tracking: Optimize guest APIs off case with static key · 48d6a816
      Frederic Weisbecker 提交于
      Optimize guest entry/exit APIs with static keys. This minimize
      the overhead for those who enable CONFIG_NO_HZ_FULL without
      always using it. Having no range passed to nohz_full= should
      result in the probes overhead to be minimized.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      48d6a816
    • F
      context_tracking: Optimize main APIs off case with static key · ad65782f
      Frederic Weisbecker 提交于
      Optimize user and exception entry/exit APIs with static
      keys. This minimize the overhead for those who enable
      CONFIG_NO_HZ_FULL without always using it. Having no range
      passed to nohz_full= should result in the probes to be nopped
      (at least we hope so...).
      
      If this proves not be enough in the long term, we'll need
      to bring an exception slow path by re-routing the exception
      handlers.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      ad65782f
    • F
      context_tracking: Ground setup for static key use · 65f382fd
      Frederic Weisbecker 提交于
      Prepare for using a static key in the context tracking subsystem.
      This will help optimizing the off case on its many users:
      
      * user_enter, user_exit, exception_enter, exception_exit, guest_enter,
        guest_exit, vtime_*()
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      65f382fd
  2. 13 8月, 2013 6 次提交
    • F
      context_tracking: Remove full dynticks' hacky dependency on wide context tracking · d84d27a4
      Frederic Weisbecker 提交于
      Now that the full dynticks subsystem only enables the context tracking
      on full dynticks CPUs, lets remove the dependency on CONTEXT_TRACKING_FORCE
      
      This dependency was a hack to enable the context tracking widely for the
      full dynticks susbsystem until the latter becomes able to enable it in a
      more CPU-finegrained fashion.
      
      Now CONTEXT_TRACKING_FORCE only stands for testing on archs that
      work on support for the context tracking while full dynticks can't be
      used yet due to unmet dependencies. It simulates a system where all CPUs
      are full dynticks so that RCU user extended quiescent states and dynticks
      cputime accounting can be tested on the given arch.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      d84d27a4
    • F
      nohz: Only enable context tracking on full dynticks CPUs · 2e709338
      Frederic Weisbecker 提交于
      The context tracking subsystem has the ability to selectively
      enable the tracking on any defined subset of CPU. This means that
      we can define a CPU range that doesn't run the context tracking
      and another range that does.
      
      Now what we want in practice is to enable the tracking on full
      dynticks CPUs only. In order to perform this, we just need to pass
      our full dynticks CPU range selection from the full dynticks
      subsystem to the context tracking.
      
      This way we can spare the overhead of RCU user extended quiescent
      state and vtime maintainance on the CPUs that are outside the
      full dynticks range. Just keep in mind the raw context tracking
      itself is still necessary everywhere.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      2e709338
    • F
      context_tracking: Fix runtime CPU off-case · d65ec121
      Frederic Weisbecker 提交于
      As long as the context tracking is enabled on any CPU, even
      a single one, all other CPUs need to keep track of their
      user <-> kernel boundaries cross as well.
      
      This is because a task can sleep while servicing an exception
      that happened in the kernel or in userspace. Then when the task
      eventually wakes up and return from the exception, the CPU needs
      to know if we resume in userspace or in the kernel. exception_exit()
      get this information from exception_enter() that saved the previous
      state.
      
      If the CPU where the exception happened didn't keep track of
      these informations, exception_exit() doesn't know which state
      tracking to restore on the CPU where the task got migrated
      and we may return to userspace with the context tracking
      subsystem thinking that we are in kernel mode.
      
      This can be fixed in the long term if we move our context tracking
      probes on very low level arch fast path user <-> kernel boundary,
      although even that is worrisome as an exception can still happen
      in the few instructions between the probe and the actual iret.
      
      Also we are not yet ready to set these probes in the fast path given
      the potential overhead problem it induces.
      
      So let's fix this by always enable context tracking even on CPUs
      that are not in the full dynticks range. OTOH we can spare the
      rcu_user_*() and vtime_user_*() calls there because the tick runs
      on these CPUs and we can handle RCU state machine and cputime
      accounting through it.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      d65ec121
    • F
      vtime: Update a few comments · 5b206d48
      Frederic Weisbecker 提交于
      Update a stale comment from the old vtime era and document some
      locking that might be non obvious.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      5b206d48
    • F
      context_tracing: Fix guest accounting with native vtime · 2d854e57
      Frederic Weisbecker 提交于
      1) If context tracking is enabled with native vtime accounting (which
      combo is useless except for dev testing), we call vtime_guest_enter()
      and vtime_guest_exit() on host <-> guest switches. But those are stubs
      in this configurations. As a result, cputime is not correctly flushed
      on kvm context switches.
      
      2) If context tracking runs but is disabled on some CPUs, those
      CPUs end up calling __guest_enter/__guest_exit which in turn
      call vtime_account_system(). We don't want to call this because we
      run in tick based accounting for these CPUs.
      
      Refactor the guest_enter/guest_exit code such that all combinations
      finally work.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      2d854e57
    • F
      sched: Consolidate open coded preemptible() checks · fbb00b56
      Frederic Weisbecker 提交于
      preempt_schedule() and preempt_schedule_context() open
      code their preemptability checks.
      
      Use the standard API instead for consolidation.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Alex Shi <alex.shi@intel.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      fbb00b56
  3. 25 7月, 2013 2 次提交
    • L
      nohz: fix compile warning in tick_nohz_init() · ca06416b
      Li Zhong 提交于
      cpu is not used after commit 5b8621a6Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      ca06416b
    • S
      nohz: Do not warn about unstable tsc unless user uses nohz_full · 543487c7
      Steven Rostedt 提交于
      If the user enables CONFIG_NO_HZ_FULL and runs the kernel on a machine
      with an unstable TSC, it will produce a WARN_ON dump as well as taint
      the kernel. This is a bit extreme for a kernel that just enables a
      feature but doesn't use it.
      
      The warning should only happen if the user tries to use the feature by
      either adding nohz_full to the kernel command line, or by enabling
      CONFIG_NO_HZ_FULL_ALL that makes nohz used on all CPUs at boot up. Note,
      this second feature should not (yet) be used by distros or anyone that
      doesn't care if NO_HZ is used or not.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      543487c7
  4. 23 7月, 2013 1 次提交
  5. 20 7月, 2013 1 次提交
  6. 19 7月, 2013 12 次提交
  7. 17 7月, 2013 1 次提交
  8. 16 7月, 2013 1 次提交
  9. 15 7月, 2013 3 次提交
    • P
      kernel: delete __cpuinit usage from all core kernel files · 0db0628d
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      This removes all the uses of the __cpuinit macros from C files in
      the core kernel directories (kernel, init, lib, mm, and include)
      that don't really have a specific maintainer.
      
      [1] https://lkml.org/lkml/2013/5/20/589Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      0db0628d
    • P
      rcu: delete __cpuinit usage from all rcu files · 49fb4c62
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      This removes all the drivers/rcu uses of the __cpuinit macros
      from all C files.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@freedesktop.org>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      49fb4c62
    • L
      PM / Sleep: avoid 'autosleep' in shutdown progress · e5248a11
      Liu ShuoX 提交于
      Prevent automatic system suspend from happening during system
      shutdown by making try_to_suspend() check system_state and return
      immediately if it is not SYSTEM_RUNNING.
      
      This prevents the following breakage from happening (scenario from
      Zhang Yanmin):
      
       Kernel starts shutdown and calls all device driver's shutdown
       callback.  When a driver's shutdown is called, the last wakelock is
       released and suspend-to-ram starts.  However, as some driver's shut
       down callbacks already shut down devices and disabled runtime pm,
       the suspend-to-ram calls driver's suspend callback without noticing
       that device is already off and causes crash.
      
      [rjw: Changelog]
      Signed-off-by: NLiu ShuoX <shuox.liu@intel.com>
      Cc: 3.5+ <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e5248a11
  10. 14 7月, 2013 1 次提交
  11. 12 7月, 2013 6 次提交
    • P
      sched: Fix HRTICK · 971ee28c
      Peter Zijlstra 提交于
      David reported that the HRTICK sched feature was borken; which was enough
      motivation for me to finally fix it ;-)
      
      We should not allow hrtimer code to do softirq wakeups while holding scheduler
      locks. The hrtimer code only needs this when we accidentally try to program an
      expired time. We don't much care about those anyway since we have the regular
      tick to fall back to.
      Reported-by: NDavid Ahern <dsahern@gmail.com>
      Tested-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20130628091853.GE29209@dyad.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      971ee28c
    • S
      tick: broadcast: Check broadcast mode on CPU hotplug · a272dcca
      Stephen Boyd 提交于
      On ARM systems the dummy clockevent is registered with the cpu
      hotplug notifier chain before any other per-cpu clockevent. This
      has the side-effect of causing the dummy clockevent to be
      registered first in every hotplug sequence. Because the dummy is
      first, we'll try to turn the broadcast source on but the code in
      tick_device_uses_broadcast() assumes the broadcast source is in
      periodic mode and calls tick_broadcast_start_periodic()
      unconditionally.
      
      On boot this isn't a problem because we typically haven't
      switched into oneshot mode yet (if at all). During hotplug, if
      the broadcast source isn't in periodic mode we'll replace the
      broadcast oneshot handler with the broadcast periodic handler and
      start emulating oneshot mode when we shouldn't. Due to the way
      the broadcast oneshot handler programs the next_event it's
      possible for it to contain KTIME_MAX and cause us to hang the
      system when the periodic handler tries to program the next tick.
      Fix this by using the appropriate function to start the broadcast
      source.
      Reported-by: NStephen Warren <swarren@nvidia.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Cc: Mark Rutland <Mark.Rutland@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: ARM kernel mailing list <linux-arm-kernel@lists.infradead.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Joseph Lo <josephl@nvidia.com>
      Link: http://lkml.kernel.org/r/20130711140059.GA27430@codeaurora.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      a272dcca
    • M
      mutex: Move ww_mutex definitions to ww_mutex.h · 1b375dc3
      Maarten Lankhorst 提交于
      Move the definitions for wound/wait mutexes out to a separate
      header, ww_mutex.h. This reduces clutter in mutex.h, and
      increases readability.
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NRik van Riel <riel@redhat.com>
      Acked-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Dave Airlie <airlied@gmail.com>
      Link: http://lkml.kernel.org/r/51D675DC.3000907@canonical.com
      [ Tidied up the code a bit. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      1b375dc3
    • P
      perf: Fix perf_lock_task_context() vs RCU · 058ebd0e
      Peter Zijlstra 提交于
      Jiri managed to trigger this warning:
      
       [] ======================================================
       [] [ INFO: possible circular locking dependency detected ]
       [] 3.10.0+ #228 Tainted: G        W
       [] -------------------------------------------------------
       [] p/6613 is trying to acquire lock:
       []  (rcu_node_0){..-...}, at: [<ffffffff810ca797>] rcu_read_unlock_special+0xa7/0x250
       []
       [] but task is already holding lock:
       []  (&ctx->lock){-.-...}, at: [<ffffffff810f2879>] perf_lock_task_context+0xd9/0x2c0
       []
       [] which lock already depends on the new lock.
       []
       [] the existing dependency chain (in reverse order) is:
       []
       [] -> #4 (&ctx->lock){-.-...}:
       [] -> #3 (&rq->lock){-.-.-.}:
       [] -> #2 (&p->pi_lock){-.-.-.}:
       [] -> #1 (&rnp->nocb_gp_wq[1]){......}:
       [] -> #0 (rcu_node_0){..-...}:
      
      Paul was quick to explain that due to preemptible RCU we cannot call
      rcu_read_unlock() while holding scheduler (or nested) locks when part
      of the read side critical section was preemptible.
      
      Therefore solve it by making the entire RCU read side non-preemptible.
      
      Also pull out the retry from under the non-preempt to play nice with RT.
      Reported-by: NJiri Olsa <jolsa@redhat.com>
      Helped-out-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      058ebd0e
    • J
      perf: Remove WARN_ON_ONCE() check in __perf_event_enable() for valid scenario · 06f41796
      Jiri Olsa 提交于
      The '!ctx->is_active' check has a valid scenario, so
      there's no need for the warning.
      
      The reason is that there's a time window between the
      'ctx->is_active' check in the perf_event_enable() function
      and the __perf_event_enable() function having:
      
        - IRQs on
        - ctx->lock unlocked
      
      where the task could be killed and 'ctx' deactivated by
      perf_event_exit_task(), ending up with the warning below.
      
      So remove the WARN_ON_ONCE() check and add comments to
      explain it all.
      
      This addresses the following warning reported by Vince Weaver:
      
      [  324.983534] ------------[ cut here ]------------
      [  324.984420] WARNING: at kernel/events/core.c:1953 __perf_event_enable+0x187/0x190()
      [  324.984420] Modules linked in:
      [  324.984420] CPU: 19 PID: 2715 Comm: nmi_bug_snb Not tainted 3.10.0+ #246
      [  324.984420] Hardware name: Supermicro X8DTN/X8DTN, BIOS 4.6.3 01/08/2010
      [  324.984420]  0000000000000009 ffff88043fce3ec8 ffffffff8160ea0b ffff88043fce3f00
      [  324.984420]  ffffffff81080ff0 ffff8802314fdc00 ffff880231a8f800 ffff88043fcf7860
      [  324.984420]  0000000000000286 ffff880231a8f800 ffff88043fce3f10 ffffffff8108103a
      [  324.984420] Call Trace:
      [  324.984420]  <IRQ>  [<ffffffff8160ea0b>] dump_stack+0x19/0x1b
      [  324.984420]  [<ffffffff81080ff0>] warn_slowpath_common+0x70/0xa0
      [  324.984420]  [<ffffffff8108103a>] warn_slowpath_null+0x1a/0x20
      [  324.984420]  [<ffffffff81134437>] __perf_event_enable+0x187/0x190
      [  324.984420]  [<ffffffff81130030>] remote_function+0x40/0x50
      [  324.984420]  [<ffffffff810e51de>] generic_smp_call_function_single_interrupt+0xbe/0x130
      [  324.984420]  [<ffffffff81066a47>] smp_call_function_single_interrupt+0x27/0x40
      [  324.984420]  [<ffffffff8161fd2f>] call_function_single_interrupt+0x6f/0x80
      [  324.984420]  <EOI>  [<ffffffff816161a1>] ? _raw_spin_unlock_irqrestore+0x41/0x70
      [  324.984420]  [<ffffffff8113799d>] perf_event_exit_task+0x14d/0x210
      [  324.984420]  [<ffffffff810acd04>] ? switch_task_namespaces+0x24/0x60
      [  324.984420]  [<ffffffff81086946>] do_exit+0x2b6/0xa40
      [  324.984420]  [<ffffffff8161615c>] ? _raw_spin_unlock_irq+0x2c/0x30
      [  324.984420]  [<ffffffff81087279>] do_group_exit+0x49/0xc0
      [  324.984420]  [<ffffffff81096854>] get_signal_to_deliver+0x254/0x620
      [  324.984420]  [<ffffffff81043057>] do_signal+0x57/0x5a0
      [  324.984420]  [<ffffffff8161a164>] ? __do_page_fault+0x2a4/0x4e0
      [  324.984420]  [<ffffffff8161665c>] ? retint_restore_args+0xe/0xe
      [  324.984420]  [<ffffffff816166cd>] ? retint_signal+0x11/0x84
      [  324.984420]  [<ffffffff81043605>] do_notify_resume+0x65/0x80
      [  324.984420]  [<ffffffff81616702>] retint_signal+0x46/0x84
      [  324.984420] ---[ end trace 442ec2f04db3771a ]---
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Suggested-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1373384651-6109-2-git-send-email-jolsa@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      06f41796
    • J
      perf: Clone child context from parent context pmu · 734df5ab
      Jiri Olsa 提交于
      Currently when the child context for inherited events is
      created, it's based on the pmu object of the first event
      of the parent context.
      
      This is wrong for the following scenario:
      
        - HW context having HW and SW event
        - HW event got removed (closed)
        - SW event stays in HW context as the only event
          and its pmu is used to clone the child context
      
      The issue starts when the cpu context object is touched
      based on the pmu context object (__get_cpu_context). In
      this case the HW context will work with SW cpu context
      ending up with following WARN below.
      
      Fixing this by using parent context pmu object to clone
      from child context.
      
      Addresses the following warning reported by Vince Weaver:
      
      [ 2716.472065] ------------[ cut here ]------------
      [ 2716.476035] WARNING: at kernel/events/core.c:2122 task_ctx_sched_out+0x3c/0x)
      [ 2716.476035] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs locn
      [ 2716.476035] CPU: 0 PID: 3164 Comm: perf_fuzzer Not tainted 3.10.0-rc4 #2
      [ 2716.476035] Hardware name: AOpen   DE7000/nMCP7ALPx-DE R1.06 Oct.19.2012, BI2
      [ 2716.476035]  0000000000000000 ffffffff8102e215 0000000000000000 ffff88011fc18
      [ 2716.476035]  ffff8801175557f0 0000000000000000 ffff880119fda88c ffffffff810ad
      [ 2716.476035]  ffff880119fda880 ffffffff810af02a 0000000000000009 ffff880117550
      [ 2716.476035] Call Trace:
      [ 2716.476035]  [<ffffffff8102e215>] ? warn_slowpath_common+0x5b/0x70
      [ 2716.476035]  [<ffffffff810ab2bd>] ? task_ctx_sched_out+0x3c/0x5f
      [ 2716.476035]  [<ffffffff810af02a>] ? perf_event_exit_task+0xbf/0x194
      [ 2716.476035]  [<ffffffff81032a37>] ? do_exit+0x3e7/0x90c
      [ 2716.476035]  [<ffffffff810cd5ab>] ? __do_fault+0x359/0x394
      [ 2716.476035]  [<ffffffff81032fe6>] ? do_group_exit+0x66/0x98
      [ 2716.476035]  [<ffffffff8103dbcd>] ? get_signal_to_deliver+0x479/0x4ad
      [ 2716.476035]  [<ffffffff810ac05c>] ? __perf_event_task_sched_out+0x230/0x2d1
      [ 2716.476035]  [<ffffffff8100205d>] ? do_signal+0x3c/0x432
      [ 2716.476035]  [<ffffffff810abbf9>] ? ctx_sched_in+0x43/0x141
      [ 2716.476035]  [<ffffffff810ac2ca>] ? perf_event_context_sched_in+0x7a/0x90
      [ 2716.476035]  [<ffffffff810ac311>] ? __perf_event_task_sched_in+0x31/0x118
      [ 2716.476035]  [<ffffffff81050dd9>] ? mmdrop+0xd/0x1c
      [ 2716.476035]  [<ffffffff81051a39>] ? finish_task_switch+0x7d/0xa6
      [ 2716.476035]  [<ffffffff81002473>] ? do_notify_resume+0x20/0x5d
      [ 2716.476035]  [<ffffffff813654f5>] ? retint_signal+0x3d/0x78
      [ 2716.476035] ---[ end trace 827178d8a5966c3d ]---
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1373384651-6109-1-git-send-email-jolsa@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      734df5ab