kernel.git/arch/arm/kernel/perf_event.c, branch linux-3.17.y

Merge branch 'devel-stable' into for-next

2014-08-05T09:27:25Z

Conflicts: arch/arm/kernel/perf_event_cpu.c

ARM: 8071/1: perf: Make perf use arm_get_current_stackframe

2014-07-18T11:29:12Z

Make the perf backend use the API so that it correctly references the FP when in THUMB2 mode Signed-off-by: Nikolay Borisov Acked-by: Will Deacon Signed-off-by: Russell King

ARM: perf: disable the pagefault handler when reading from user space

2014-07-09T14:05:29Z

Under perf, the fp unwinding scheme requires access to user space memory and can provoke a pagefault via call to __copy_from_user_inatomic from user_backtrace. This unwinding can take place in response to an interrupt (__perf_event_overflow). This is undesirable as we may already have mmap_sem held for write. One example being a process that calls mprotect just as a the PMU counters overflow. An example that can provoke this behaviour: perf record -e event:tocapture --call-graph fp ./application_to_test This patch addresses this issue by disabling pagefaults briefly in user_backtrace (as is done in the other architectures: ARM64, x86, Sparc etc.). Without the patch a deadlock occurs when __perf_event_overflow is called while reading the data from the user space: [ INFO: possible recursive locking detected ] 3.16.0-rc2-00038-g0ed7ff6 #46 Not tainted --------------------------------------------- stress/1634 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [] do_page_fault+0xa8/0x428 but task is already holding lock: (&mm->mmap_sem){++++++}, at: [] SyS_mprotect+0xa8/0x1c8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&mm->mmap_sem); lock(&mm->mmap_sem); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by stress/1634: #0: (&mm->mmap_sem){++++++}, at: [] SyS_mprotect+0xa8/0x1c8 #1: (rcu_read_lock){......}, at: [] __perf_event_overflow+0x120/0x294 stack backtrace: CPU: 1 PID: 1634 Comm: stress Not tainted 3.16.0-rc2-00038-g0ed7ff6 #46 [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0x7c/0x98) [] (dump_stack) from [] (__lock_acquire+0x1484/0x1cf0) [] (__lock_acquire) from [] (lock_acquire+0xa4/0x11c) [] (lock_acquire) from [] (down_read+0x40/0x7c) [] (down_read) from [] (do_page_fault+0xa8/0x428) [] (do_page_fault) from [] (do_DataAbort+0x44/0xa8) [] (do_DataAbort) from [] (__dabt_svc+0x3c/0x60) Exception stack(0xed7c5ae0 to 0xed7c5b28) 5ae0: ed7c5b5c b6dadff4 ffffffec 00000000 b6dadff4 ebc08000 00000000 ebc08000 5b00: 0000007e 00000000 ed7c4000 ed7c5b94 00000014 ed7c5b2c c001a438 c0236c60 5b20: 00000013 ffffffff [] (__dabt_svc) from [] (__copy_from_user+0xa4/0x3a4) Acked-by: Steve Capper Signed-off-by: Jean Pihet Signed-off-by: Will Deacon

ARM: perf: Check that current->mm is alive before getting user callchain

2014-07-09T14:05:24Z

An event may occur when an mm is already released. As per commit 20afc60f892d285fde179ead4b24e6a7938c2f1b 'x86, perf: Check that current->mm is alive before getting user callchain' Acked-by: Will Deacon Signed-off-by: Jean Pihet Signed-off-by: Will Deacon

perf/ARM: Use common PMU interrupt disabled code

2014-06-05T10:30:00Z

Make the ARM perf code use the new common PMU interrupt disabled code. This allows perf to work on ARM machines without a working PMU interrupt (for example, raspberry pi). Acked-by: Will Deacon Signed-off-by: Vince Weaver [peterz: applied changes suggested by Will] Signed-off-by: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Grant Likely Cc: Linus Torvalds Cc: Paul Mackerras Cc: Rob Herring Cc: Russell King Cc: Will Deacon Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1405161712190.11099@vincent-weaver-1.umelst.maine.edu [ Small readability tweaks to the code. ] Signed-off-by: Ingo Molnar Signed-off-by: Ingo Molnar

ARM: perf: hook up perf_sample_event_took around pmu irq handling

2014-02-21T11:11:21Z

Since we indirect all of our PMU IRQ handling through a dispatcher, it's trivial to hook up perf_sample_event_took to prevent applications such as oprofile from generating interrupt storms due to an unrealisticly low sample period. Reported-by: Robert Richter Signed-off-by: Will Deacon

ARM: perf: add hook for event index clearing

2014-02-21T11:11:08Z

On Krait processors we have a many-to-one relationship between raw CPU events and the event programmed into the PMNx counter. Two raw CPU events could map to the same value programmed in the PMNx counter. To avoid this problem, we check for collisions during the get_event_idx() callback by setting a bit in a bitmap whenever a certain event is used in a PMNx counter (see the next patch). Unfortunately, we don't have a hook to clear this bit in the bitmap when the event is deleted so let's add an optional clear_event_idx() callback for this purpose. Signed-off-by: Stephen Boyd Signed-off-by: Will Deacon

ARM: perf: support percpu irqs for the CPU PMU

2014-02-21T11:10:44Z

Some CPU PMUs are wired up with one PPI for all the CPUs instead of with a different SPI for each CPU. Add support for these devices. Signed-off-by: Stephen Boyd Signed-off-by: Will Deacon

Revert "ARM: 7556/1: perf: fix updated event period in response to PERF_EVENT_IOC_PERIOD"

2013-12-17T14:21:35Z

This reverts commit 3581fe0ef37ce12ac7a4f74831168352ae848edc. Fixes to the handling of PERF_EVENT_IOC_PERIOD in the core code mean we no longer have to play this horrible game. Signed-off-by: Will Deacon Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/1385560479-11014-2-git-send-email-will.deacon@arm.com Signed-off-by: Ingo Molnar

ARM: perf: fix group validation for mixed software and hardware groups

2013-10-09T13:33:07Z

Since software events can always be scheduled, perf allows software and hardware events to be mixed together in the same event group. There are two ways in which this can come about: (1) A SW event is added to a HW group. This validates using the HW PMU of the group leader. (2) A HW event is added to a SW group. This inserts the SW events and the new HW event into a HW context, but the SW event remains the group leader. When validating the latter case, we would ideally compare the PMU of each event in the group with the relevant HW PMU. The problem is, in the face of potentially multiple HW PMUs, we don't have a handle on the relevant structure. Commit 7b9f72c62ed0 ("ARM: perf: clean up event group validation") attempting to resolve this issue, but actually made things *worse* by comparing with the leader PMU. If the leader is a SW event, then we automatically `pass' all the HW events during validation! This patch removes the check against the leader PMU. Whilst this will allow events from multiple HW PMUs to be grouped together, that should probably be dealt with in perf core as the result of a later patch. Acked-by: Mark Rutland Signed-off-by: Will Deacon