1. 11 Feb, 2015 3 commits
  2. 07 Feb, 2015 7 commits
  3. 06 Feb, 2015 9 commits
  4. 04 Feb, 2015 8 commits
    • Mark Rutland's avatar
      perf: Decouple unthrottling and rotating · 2fde4f94
      Mark Rutland authored
      Currently the adjusments made as part of perf_event_task_tick() use the
      percpu rotation lists to iterate over any active PMU contexts, but these
      are not used by the context rotation code, having been replaced by
      separate (per-context) hrtimer callbacks. However, some manipulation of
      the rotation lists (i.e. removal of contexts) has remained in
      perf_rotate_context(). This leads to the following issues:
      
      * Contexts are not always removed from the rotation lists. Removal of
        PMUs which have been placed in rotation lists, but have not been
        removed by a hrtimer callback can result in corruption of the rotation
        lists (when memory backing the context is freed).
      
        This has been observed to result in hangs when PMU drivers built as
        modules are inserted and removed around the creation of events for
        said PMUs.
      
      * Contexts which do not require rotation may be removed from the
        rotation lists as a result of a hrtimer, and will not be considered by
        the unthrottling code in perf_event_task_tick.
      
      This patch fixes the issue by updating the rotation ist when events are
      scheduled in/out, ensuring that each rotation list stays in sync with
      the HW state. As each event holds a refcount on the module of its PMU,
      this ensures that when a PMU module is unloaded none of its CPU contexts
      can be in a rotation list. By maintaining a list of perf_event_contexts
      rather than perf_event_cpu_contexts, we don't need separate paths to
      handle the cpu and task contexts, which also makes the code a little
      simpler.
      
      As the rotation_list variables are not used for rotation, these are
      renamed to active_ctx_list, which better matches their current function.
      perf_pmu_rotate_{start,stop} are renamed to
      perf_pmu_ctx_{activate,deactivate}.
      Reported-by: default avatarJohannes Jensen <johannes.jensen@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Will Deacon <Will.Deacon@arm.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20150129134511.GR17721@leverpostejSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      2fde4f94
    • Mark Rutland's avatar
      perf: Drop module reference on event init failure · cc34b98b
      Mark Rutland authored
      When initialising an event, perf_init_event will call try_module_get() to
      ensure that the PMU's module cannot be removed for the lifetime of the
      event, with __free_event() dropping the reference when the event is
      finally destroyed. If something fails after the event has been
      initialised, but before the event is installed, perf_event_alloc will
      drop the reference on the module.
      
      However, if we fail to initialise an event for some reason (e.g. we ask
      an uncore PMU to perform sampling, and it refuses to initialise the
      event), we do not drop the refcount. If we try to open such a bogus
      event without a precise IDR type, we will loop over each PMU in the pmus
      list, incrementing each of their refcounts without decrementing them.
      
      This patch adds a module_put when pmu->event_init(event) fails, ensuring
      that the refcounts are balanced in failure cases. As the innards of the
      precise and search based initialisation look very similar, this logic is
      hoisted out into a new helper function. While the early return for the
      failed try_module_get is removed from the search case, this is handled
      by the remaining return when ret is not -ENOENT.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1420642611-22667-1-git-send-email-mark.rutland@arm.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      cc34b98b
    • Jiri Olsa's avatar
      perf: Use POLLIN instead of POLL_IN for perf poll data in flag · 7c60fc0e
      Jiri Olsa authored
      Currently we flag available data (via poll syscall) on perf fd with
      POLL_IN macro, which is normally used for SIGIO interface.
      
      We've been lucky, because POLLIN (0x1) is subset of POLL_IN (0x20001)
      and sys_poll (do_pollfd function) cut the extra bit out (0x20000).
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1422467678-22341-1-git-send-email-jolsa@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7c60fc0e
    • Peter Zijlstra's avatar
      perf: Fix put_event() ctx lock · a83fe28e
      Peter Zijlstra authored
      So what I suspect; but I'm in zombie mode today it seems; is that while
      I initially thought that it was impossible for ctx to change when
      refcount dropped to 0, I now suspect its possible.
      
      Note that until perf_remove_from_context() the event is still active and
      visible on the lists. So a concurrent sys_perf_event_open() from another
      task into this task can race.
      Reported-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@gmail.com>
      Cc: mark.rutland@arm.com
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20150129134434.GB26304@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a83fe28e
    • Peter Zijlstra (Intel)'s avatar
      perf: Fix move_group() order · 8f95b435
      Peter Zijlstra (Intel) authored
      Jiri reported triggering the new WARN_ON_ONCE in event_sched_out over
      the weekend:
      
        event_sched_out.isra.79+0x2b9/0x2d0
        group_sched_out+0x69/0xc0
        ctx_sched_out+0x106/0x130
        task_ctx_sched_out+0x37/0x70
        __perf_install_in_context+0x70/0x1a0
        remote_function+0x48/0x60
        generic_exec_single+0x15b/0x1d0
        smp_call_function_single+0x67/0xa0
        task_function_call+0x53/0x80
        perf_install_in_context+0x8b/0x110
      
      I think the below should cure this; if we install a group leader it
      will iterate the (still intact) group list and find its siblings and
      try and install those too -- even though those still have the old
      event->ctx -- in the new ctx.
      
      Upon installing the first group sibling we'd try and schedule out the
      group and trigger the above warn.
      
      Fix this by installing the group leader last, installing siblings
      would have no effect, they're not reachable through the group lists
      and therefore we don't schedule them.
      
      Also delay resetting the state until we're absolutely sure the events
      are quiescent.
      Reported-by: default avatarJiri Olsa <jolsa@redhat.com>
      Reported-by: vincent.weaver@maine.edu
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20150126162639.GA21418@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      8f95b435
    • Peter Zijlstra's avatar
      perf: Fix event->ctx locking · f63a8daa
      Peter Zijlstra authored
      There have been a few reported issues wrt. the lack of locking around
      changing event->ctx. This patch tries to address those.
      
      It avoids the whole rwsem thing; and while it appears to work, please
      give it some thought in review.
      
      What I did fail at is sensible runtime checks on the use of
      event->ctx, the RCU use makes it very hard.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20150123125834.209535886@infradead.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f63a8daa
    • Peter Zijlstra's avatar
      perf: Add a bit of paranoia · 652884fe
      Peter Zijlstra authored
      Add a few WARN()s to catch things that should never happen.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20150123125834.150481799@infradead.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      652884fe
    • Ingo Molnar's avatar
  5. 02 Feb, 2015 1 commit
  6. 01 Feb, 2015 5 commits
    • Linus Torvalds's avatar
      Merge tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · fba7e994
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "One more week's worth of fixes.  Worth pointing out here are:
      
         - A patch fixing detaching of iommu registrations when a device is
           removed -- earlier the ops pointer wasn't managed properly
         - Another set of Renesas boards get the same GIC setup fixup as
           others have in previous -rcs
         - Serial port aliases fixups for sunxi.  We did the same to tegra but
           we caught that in time before the merge window due to more machines
           being affected.  Here it took longer for anyone to notice.
         - A couple more DT tweaks on sunxi
         - A follow-up patch for the mvebu coherency disabling in last -rc
           batch"
      
      * tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        arm: dma-mapping: Set DMA IOMMU ops in arm_iommu_attach_device()
        ARM: shmobile: r8a7790: Instantiate GIC from C board code in legacy builds
        ARM: shmobile: r8a73a4: Instantiate GIC from C board code in legacy builds
        ARM: mvebu: don't set the PL310 in I/O coherency mode when I/O coherency is disabled
        ARM: sunxi: dt: Fix aliases
        ARM: dts: sun4i: Add simplefb node with de_fe0-de_be0-lcd0-hdmi pipeline
        ARM: dts: sun6i: ippo-q8h-v5: Fix serial0 alias
        ARM: dts: sunxi: Fix usb-phy support for sun4i/sun5i
      fba7e994
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · 3441456b
      Linus Torvalds authored
      Pull input layer updates from Dmitry Torokhov:
       "Just a few quirks for PS/2 this time"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
        Input: elantech - add more Fujtisu notebooks to force crc_enabled
        Input: i8042 - add noloop quirk for Medion Akoya E7225 (MD98857)
        Input: synaptics - adjust min/max for Lenovo ThinkPad X1 Carbon 2nd
      3441456b
    • Linus Torvalds's avatar
      sched: don't cause task state changes in nested sleep debugging · 00845eb9
      Linus Torvalds authored
      Commit 8eb23b9f ("sched: Debug nested sleeps") added code to report
      on nested sleep conditions, which we generally want to avoid because the
      inner sleeping operation can re-set the thread state to TASK_RUNNING,
      but that will then cause the outer sleep loop not actually sleep when it
      calls schedule.
      
      However, that's actually valid traditional behavior, with the inner
      sleep being some fairly rare case (like taking a sleeping lock that
      normally doesn't actually need to sleep).
      
      And the debug code would actually change the state of the task to
      TASK_RUNNING internally, which makes that kind of traditional and
      working code not work at all, because now the nested sleep doesn't just
      sometimes cause the outer one to not block, but will cause it to happen
      every time.
      
      In particular, it will cause the cardbus kernel daemon (pccardd) to
      basically busy-loop doing scheduling, converting a laptop into a heater,
      as reported by Bruno Prémont.  But there may be other legacy uses of
      that nested sleep model in other drivers that are also likely to never
      get converted to the new model.
      
      This fixes both cases:
      
       - don't set TASK_RUNNING when the nested condition happens (note: even
         if WARN_ONCE() only _warns_ once, the return value isn't whether the
         warning happened, but whether the condition for the warning was true.
         So despite the warning only happening once, the "if (WARN_ON(..))"
         would trigger for every nested sleep.
      
       - in the cases where we knowingly disable the warning by using
         "sched_annotate_sleep()", don't change the task state (that is used
         for all core scheduling decisions), instead use '->task_state_change'
         that is used for the debugging decision itself.
      
      (Credit for the second part of the fix goes to Oleg Nesterov: "Can't we
      avoid this subtle change in behaviour DEBUG_ATOMIC_SLEEP adds?" with the
      suggested change to use 'task_state_change' as part of the test)
      Reported-and-bisected-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Tested-by: default avatarRafael J Wysocki <rjw@rjwysocki.net>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>,
      Cc: Ilya Dryomov <ilya.dryomov@inktank.com>,
      Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Hurley <peter@hurleysoftware.com>,
      Cc: Davidlohr Bueso <dave@stgolabs.net>,
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      00845eb9
    • Rainer Koenig's avatar
      Input: elantech - add more Fujtisu notebooks to force crc_enabled · 47c1ffb2
      Rainer Koenig authored
      Add two more Fujitsu LIFEBOOK models that also ship with the Elantech
      touchpad and don't work with crc_disabled to the quirk list.
      Signed-off-by: default avatarRainer Koenig <Rainer.Koenig@ts.fujitsu.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      47c1ffb2
    • Olof Johansson's avatar
      Merge tag 'renesas-soc-fixes3-for-v3.19' of... · 28111dda
      Olof Johansson authored
      Merge tag 'renesas-soc-fixes3-for-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
      
      Merge "Third Round of Renesas ARM Based SoC Fixes for v3.19" from Simon Horman:
      
      * Instantiate GIC from C board code in legacy builds on r8a7790 and r8a73a4
      
      * tag 'renesas-soc-fixes3-for-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
        ARM: shmobile: r8a7790: Instantiate GIC from C board code in legacy builds
        ARM: shmobile: r8a73a4: Instantiate GIC from C board code in legacy builds
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      28111dda
  7. 31 Jan, 2015 4 commits
  8. 30 Jan, 2015 3 commits