day to the
architectures that deliver PMIs as IRQs. Mathieu?
[1]
https://git.kernel.org/cgit/linux/kernel/git/ash/linux.git/log/?h=perf-aux-sampling
Alexander Shishkin (6):
perf: Move mlock accounting to ring buffer allocation
perf: Add api to (de-)allocate AUX buffers for kernel counters
p
Commit-ID: 3bf6215a1b30db7df6083c708caab3fe1a8e8abe
Gitweb: http://git.kernel.org/tip/3bf6215a1b30db7df6083c708caab3fe1a8e8abe
Author: Alexander Shishkin
AuthorDate: Tue, 20 Sep 2016 18:48:11 +0300
Committer: Ingo Molnar
CommitDate: Thu, 22 Sep 2016 14:56:09 +0200
perf/core: Limit
Commit-ID: 08b90f0655258411a1b41d856331e20e7ec8d55c
Gitweb: http://git.kernel.org/tip/08b90f0655258411a1b41d856331e20e7ec8d55c
Author: Alexander Shishkin
AuthorDate: Tue, 20 Sep 2016 18:48:10 +0300
Committer: Ingo Molnar
CommitDate: Thu, 22 Sep 2016 14:56:08 +0200
perf/x86/intel/bts
s
that may prevent this, but those would be hardware-specific). However,
the exclusivity code is written so that only one event from any of the
"exclusive" PMUs is allowed in a context.
Fix this by making the exclusive event filter explicitly match two events'
PMUs.
Signed-o
hy on systems that allow coexistance of PT and BTS it still works,
see ccbebba4c6 for more context).
Alexander Shishkin (2):
perf/x86/intel/bts: Make it an exclusive PMU
perf: Limit matching exclusive events to one PMU
arch/x86/events/intel/bts.c | 3 ++-
kernel/events/core.c| 2 +-
2
scheduled and receive the actual trace data.
Fix this by making intel_bts an "exclusive" PMU.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/bts.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/b
Alexander Shishkin writes:
> Sebastian Andrzej Siewior writes:
>
>> From: Sebastian Andrzej Siewior
>>
>> Since commit 4d4c47412464 ("perf/x86/intel/bts: Fix BTS PMI detection")
>> my box goes boom on boot:
>>
>> | node #0, CPUs:
Sebastian Andrzej Siewior writes:
> From: Sebastian Andrzej Siewior
>
> Since commit 4d4c47412464 ("perf/x86/intel/bts: Fix BTS PMI detection")
> my box goes boom on boot:
>
> | node #0, CPUs: #1 #2 #3 #4 #5 #6 #7
> | BUG: unable to handle kernel NULL pointer dereference at 00
Commit-ID: 8ee83b2ab3d1987cbd80c9f2c6f2b12fed87b51e
Gitweb: http://git.kernel.org/tip/8ee83b2ab3d1987cbd80c9f2c6f2b12fed87b51e
Author: Alexander Shishkin
AuthorDate: Fri, 16 Sep 2016 16:48:19 +0300
Committer: Thomas Gleixner
CommitDate: Tue, 20 Sep 2016 01:18:28 +0200
perf/x86/intel
ion
to take these into account.
Cc: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 24 +++-
arch/x86/events/intel/pt.h | 5 +
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/inte
Commit-ID: 1155bafcb79208abc6ae234c6e135ac70607755c
Gitweb: http://git.kernel.org/tip/1155bafcb79208abc6ae234c6e135ac70607755c
Author: Alexander Shishkin
AuthorDate: Thu, 15 Sep 2016 18:13:52 +0300
Committer: Ingo Molnar
CommitDate: Fri, 16 Sep 2016 11:14:16 +0200
perf/x86/intel/pt
Commit-ID: ddfdad991e55b65c1cc4ee29502f6dceee04455a
Gitweb: http://git.kernel.org/tip/ddfdad991e55b65c1cc4ee29502f6dceee04455a
Author: Alexander Shishkin
AuthorDate: Thu, 15 Sep 2016 18:13:51 +0300
Committer: Ingo Molnar
CommitDate: Fri, 16 Sep 2016 11:14:16 +0200
perf/x86/intel/pt
Commit-ID: 95f60084acbcee6c466256cf26eb52191fad9edc
Gitweb: http://git.kernel.org/tip/95f60084acbcee6c466256cf26eb52191fad9edc
Author: Alexander Shishkin
AuthorDate: Thu, 15 Sep 2016 18:13:50 +0300
Committer: Ingo Molnar
CommitDate: Fri, 16 Sep 2016 11:14:16 +0200
perf/x86/intel/pt
bits (like 0xf00d) throws a #GP.
This patch adds address validation for the user supplied kernel filters.
Cc: sta...@vger.kernel.org # v4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 7 ++-
1 file changed, 6 insertions(+), 1 del
sized filters don't pass the filter
validation.
Cc: sta...@vger.kernel.org # v4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/
Hi again,
Apologies for the botched recipient list in the previous one. So I
moved the virt_addr_valid() inside pt.c as well to save cycles in the
LBR code.
These are 3 bugs that Adrian found; all 3 seem like good -stable
candidates.
Alexander Shishkin (3):
perf/x86/intel/pt: Fix an off-by
this calculation.
Cc: sta...@vger.kernel.org # v4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 1f94963a28..861a7
bits (like 0xf00d) throws a #GP.
In the interest of improving everybody's kernel address checks, this
patch adds address validation to kernel_ip().
Cc: sta...@vger.kernel.org # 4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/perf_event.h | 2
this calculation.
Cc: sta...@vger.kernel.org # 4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 5ec0100e3f..834ce
sized filters don't pass the filter
validation.
Cc: sta...@vger.kernel.org # 4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/
least theoretically.
Alexander Shishkin (3):
perf/x86/intel/pt: Fix an off-by-one in address filter configuration
perf/x86: Tighten up the kernel_ip() check
perf/x86/intel/pt: Do validate the size of a kernel address filter
arch/x86/events/intel/pt.c | 13 +
arch/x86/events/perf_event.h
Commit-ID: cecf62352aee2b4fe114aafd1b8c5f265a4243ce
Gitweb: http://git.kernel.org/tip/cecf62352aee2b4fe114aafd1b8c5f265a4243ce
Author: Alexander Shishkin
AuthorDate: Thu, 15 Sep 2016 11:22:33 +0300
Committer: Ingo Molnar
CommitDate: Thu, 15 Sep 2016 11:25:26 +0200
perf/x86/intel
This patch moves intel_bts enabling/disabling directly to the PMI
handler.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/core.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
Vince Weaver writes:
> Hello
>
> I'm running 4.8-rc6 git from this morning (with the various perf fixes).
>
> Fuzzing on Skylake I still managed to trigger the following warning.
I was sure that I'd sent the fix for this one in the earlier series, but
somehow I missed it. Sending now.
Thanks,
-
Commit-ID: a9a94401c2b5805c71e39427b1af1bf1b9f67cd0
Gitweb: http://git.kernel.org/tip/a9a94401c2b5805c71e39427b1af1bf1b9f67cd0
Author: Alexander Shishkin
AuthorDate: Tue, 6 Sep 2016 16:23:51 +0300
Committer: Ingo Molnar
CommitDate: Sat, 10 Sep 2016 11:15:37 +0200
perf/x86/intel/bts
Commit-ID: b79ccadd6bb10e72cf784a298ca6dc1398eb9a24
Gitweb: http://git.kernel.org/tip/b79ccadd6bb10e72cf784a298ca6dc1398eb9a24
Author: Alexander Shishkin
AuthorDate: Tue, 6 Sep 2016 16:23:50 +0300
Committer: Ingo Molnar
CommitDate: Sat, 10 Sep 2016 11:15:36 +0200
perf/core: Fix
Commit-ID: 4d4c474124649198d9b0a065c06f9362cf18e14e
Gitweb: http://git.kernel.org/tip/4d4c474124649198d9b0a065c06f9362cf18e14e
Author: Alexander Shishkin
AuthorDate: Tue, 6 Sep 2016 16:23:52 +0300
Committer: Ingo Molnar
CommitDate: Sat, 10 Sep 2016 11:15:38 +0200
perf/x86/intel/bts
Commit-ID: 767ae08678c2c796bcd7f582ee457aee20a28a1e
Gitweb: http://git.kernel.org/tip/767ae08678c2c796bcd7f582ee457aee20a28a1e
Author: Alexander Shishkin
AuthorDate: Tue, 6 Sep 2016 16:23:49 +0300
Committer: Ingo Molnar
CommitDate: Sat, 10 Sep 2016 11:15:36 +0200
perf/core: Fix a race
Commit-ID: ef9ef3befa0d76008e988a9ed9fe439e803351b9
Gitweb: http://git.kernel.org/tip/ef9ef3befa0d76008e988a9ed9fe439e803351b9
Author: Alexander Shishkin
AuthorDate: Tue, 6 Sep 2016 16:23:53 +0300
Committer: Ingo Molnar
CommitDate: Sat, 10 Sep 2016 11:15:38 +0200
perf/x86/intel/bts
Vince Weaver writes:
> On the skylake machine with the original 5 patches I got this after
> continuing to fuzz. Sorry about the lack of frame pointer, next
> compile will have it enabled.
>
> If it matters, prior to this I hit the unrelated
> [25510.278199] WARNING: CPU: 1 PID: 25405 at kernel
Ingo Molnar writes:
> * Alexander Shishkin wrote:
>
>> Ingo Molnar writes:
>>
>> > * Alexander Shishkin wrote:
>> >
>> >> Hi,
>> >>
>> >> There were more bugs since the previous version, plus the BTS barriers
>
Vince Weaver writes:
> On Wed, 7 Sep 2016, Alexander Shishkin wrote:
>
>> Sure. And yes, I did catch a warning, which calls for one more patch
>> (below). Also one unrelated thing in PEBS that Peter fixed.
>
> Does that fix this which I just got on my skylake machine (4.
Ingo Molnar writes:
> * Alexander Shishkin wrote:
>
>> Hi,
>>
>> There were more bugs since the previous version, plus the BTS barriers got
>> fixed. With these patches, my testcase keeps running and no spurious NMI
>> warnings pop up any more.
>
>
At the moment, intel_bts will WARN() out if there is more than one
event writing to the same ring buffer, via SET_OUTPUT, and will only
send data from one event to a buffer.
There is no reason to have this warning in, so kill it.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel
t the interrupt
threshold.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/bts.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c
index 61e1d713b1..9233edf993 100644
--- a/arch/x86/events/
5/0x80
> [] sys_sched_yield+0x61/0x70
> [] entry_SYSCALL_64_fastpath+0x18/0xa8
> ---[ end trace 6235f556f5ea83a9 ]---
This patch puts the checks in perf_aux_output_begin() in the same order
as that of perf_mmap_close().
Signed-off-by: Alexander Shishkin
---
kernel/events/ring_buffer.c | 16
nd
panics.
The general ordering rule that is patch is enforcing is that this
cpu-local variable be set only when the cpu-local AUX transaction is
active; consequently, this variable is to be checked before the AUX
related bits can be touched.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/in
started, its new ring buffer will
be used. If another SET_OUTPUT comes and switches it back to the
old ring buffer that's getting unmapped, it's also fine: this
ring buffer's aux_mmap_count will be zero and AUX transactions won't
start any more.
Signed-off-by: Alexander
.
These are all good candidates for 4.7-stable and the BTS ones can be
theoretically backported further.
Alexander Shishkin (5):
perf: Fix a race between mmap_close and set_output of AUX events
perf: Fix aux_mmap_count vs aux_refcount order
perf/x86/intel/bts: Fix confused ordering of PMU
Greg KH writes:
>> git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git
>> tags/stm-for-greg-20160701
>
> I'm already all caught up with stm patches, right? If not, can you
> resend the pull requests?
Yes, you are all caught up with stm/intel_th indeed. Thank you for
confirming though!
Peter Zijlstra writes:
> On Wed, Aug 24, 2016 at 05:15:54PM +0300, Alexander Shishkin wrote:
>> @@ -221,10 +245,13 @@ static void __bts_event_start(struct perf_event *event)
>>
>> /*
>> * local barrier to make sure that ds configuration made it
>
Yes, Will's patch notwithstanding, these patches fix the
warnings/oopses that you observed.
On 26 August 2016 at 23:49, Vince Weaver wrote:
> On Wed, 24 Aug 2016, Alexander Shishkin wrote:
>
>> Alexander Shishkin writes:
>>
>> > Alexander Shishkin writes:
>
Alexander Shishkin writes:
> Alexander Shishkin writes:
>
>> Signed-off-by: Alexander Shishkin
>
> Ok, this one is broken, please disregard.
Vince, can you try the following (with the other two in this series)?
---
>From 68713194b3df8e565c4d319a80e9e7338fa1ec13 Mon Sep
Alexander Shishkin writes:
> The intel_bts driver is using a cpu-local 'started' variable to order
> callbacks and PMIs and make sure that AUX transactions don't get messed
> up. However, the ordering rules in regard to this variable is a complete
> mess, which recen
ssing. Thanks!
> This patch uses this_cpu_ptr instead of get_cpu_ptr, since preemption is
> already disabled by the caller.
>
> Fixes: 95ff4ca26c49 ("perf/core: Free AUX pages in unmap path")
> Cc: Alexander Shishkin
> Cc: Peter Zijlstra
> Signed-off-by: Will Deacon
Reviewed-by: Alexander Shishkin
Regards,
--
Alex
Thanks! I'll get back to you with something better.
On 23 August 2016 at 23:55, Vince Weaver wrote:
> On Tue, 23 Aug 2016, Alexander Shishkin wrote:
>
>> Vince Weaver writes:
>>
>> > On Tue, 23 Aug 2016, Alexander Shishkin wrote:
>> >
>> >> R
Vince Weaver writes:
> On Tue, 23 Aug 2016, Alexander Shishkin wrote:
>
>> Recently Vince has reported warnings and panics coming from the
>> general direction of AUX tracing. I found two bugs which manifest
>> similarly, one in intel_bts driver and one in AUX unmappi
Will Deacon writes:
> Hi Alexander,
>
> On Fri, Aug 12, 2016 at 08:54:49PM +0300, Alexander Shishkin wrote:
>> Yes, I tracked to a race between unmapping and set_output, trying to
>> come up with a good fix now.
>
> Did you get anywhere with this? I think I just hi
Mathieu Poirier writes:
> On 22 August 2016 at 09:15, Alexander Shishkin
> wrote:
>> Mathieu Poirier writes:
>>
>>> As such something that used to be a two-step process:
>>>
>>> # echo 1 > /sys/bus/coresight/devices/2007.etr/enable_sink
&g
test case that set fire to the kernel
within a few seconds by doing this, which I can share if anyone
cares.
These are all good candidates for 4.7-stable and the BTS ones can be
theoretically backported further.
Alexander Shishkin (3):
perf/x86/intel/bts: Fix confused ordering of PMU callbacks
At the moment, intel_bts will WARN() out if there is more than one
event writing to the same ring buffer, via SET_OUTPUT, and will only
send data from one event to a buffer.
There is no reason to have this warning in, so kill it.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel
nd
panics.
The general ordering rule that is patch is enforcing is that this
cpu-local variable be set only when the cpu-local AUX transaction is
active; consequently, this variable is to be checked before the AUX
related bits can be touched.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/i
started, its new ring buffer will
be used. If another SET_OUTPUT comes and switches it back to the
old ring buffer that's getting unmapped, it's also fine: this
ring buffer's aux_mmap_count will be zero and AUX transactions won't
start any more.
Signed-off-by: Alexander
Mathieu Poirier writes:
> +enum {
> + ETM_TOKEN_SINK_CPU,
> + ETM_TOKEN_SINK,
> + ETM_TOKEN_ERR,
> +};
> +
> +static const match_table_t drv_cfg_tokens = {
> + {ETM_TOKEN_SINK_CPU, "sink=cpu%d:%s"},
> + {ETM_TOKEN_SINK, "sink=%s"},
> + {ETM_TOKEN_ERR, NULL},
> +};
Wait, b
Mathieu Poirier writes:
> This patch somewhat mimics the work done on address filters to
> add the infrastructure needed to pass PMU specific HW
> configuration to the driver before a session starts.
Looks like a lot of work to do something that can be taken care of
entirely in userspace. A few
Mathieu Poirier writes:
> As such something that used to be a two-step process:
>
> # echo 1 > /sys/bus/coresight/devices/2007.etr/enable_sink
> # perf record -e cs_etm//u --per-thread uname
>
> is integrated in a single command:
>
> # perf record -e cs_etm/@sink=2007.etr/u --per-thread
Yes, I tracked to a race between unmapping and set_output, trying to
come up with a good fix now.
On 12 August 2016 at 20:17, Vince Weaver wrote:
>
> On Tue, 9 Aug 2016, Alexander Shishkin wrote:
>
>>
>> Awesome, I'll have a look. Can you tell it it was messing aroun
Vince Weaver writes:
> Hello
>
> running the perf_fuzzer on Haswell, this is a new warning I don't think
> I've seen before.
>
> It works out to be this code here:
>
> /* this has to be the last one */
> rb_free_aux(rb);
> WARN_ON_ONCE(atomic_read(
han just the CPU number so that
>> individual drivers can make the right configuration when setting
>> up a session.
>>
>> Signed-off-by: Mathieu Poirier
>> Cc: Alexander Shishkin
>
> Yeah, no objection to this.
Sure, but I'd like a commit message that actually describes *what*
information and *why*.
Regards,
--
Alex
Mathieu Poirier writes:
> This is the second wave of a patchset that address miscellaneous bugs
> encountered while implementing address filtering on CoreSight.
>
> The set has been tested, and applies cleanly, on 4.7-rc7.
Thanks!
FWIW, this series:
Acked-by: Alexander Shishk
Mathieu Poirier writes:
> Good day Alex and friends,
>
> I'm sending you a few patches that address bugs I've encounter while
> implementing address filtering on CoreSight. I especially draw your
> attention to patch 2/3 - I am pretty sure the same problem can be
> found in the x86 world.
Yes,
Mathieu Poirier writes:
> At this time function perf_addr_filter_needs_mmap() will _not_
> return true on a user space 'stop' filter. But stop filters
> needs exactly the same kind of mapping that range and start
> filters get.
Indeed.
>
> Signed-off-by: Mathieu Poirier
> ---
> kernel/events
Mathieu Poirier writes:
> Function perf_event_mmap() is called by the MM subsystem each time
> part of a binary is loaded in memory. There can be several mapping
> for a binary, many times unrelated to the code section.
>
> Each time a section of a binary is mapped address filters are
> updated,
Mathieu Poirier writes:
> Binary file names have to be supplied for both range and start/stop
> filters but the current code only process the filename if an
> address range filter is specified. This code adds processing of
> the filename for start/stop filters.
>
> Signed-off-by: Mathieu Poirier
Greg KH writes:
> On Fri, Jul 01, 2016 at 12:15:37PM +0300, Alexander Shishkin wrote:
>> Hi Greg,
>>
>> These are fixes I have queued for the v4.7. Please consider pulling into
>> char-misc-linus.
>>
>> The following changes since commit 6
/intel_th: Updates for 4.8
These are:
* runtime power management implementation for both intel_th and stm class
* semi-random kerneldoc fixes
Alexander Shishkin (4):
stm class: Add runtime power management handling
)
intel_th: Fixes for 4.7
These are:
* a fix for a modprobe time deadlock
* a new PCI ID for Kaby Lake PCH-H
Alexander Shishkin (2):
intel_th: Fix a deadlock in modprobing
intel_th: pci: Add Kaby Lake PCH-H support
drivers
Mathieu Poirier writes:
> On 30 June 2016 at 09:30, Alexander Shishkin
> wrote:
>> Mathieu Poirier writes:
>>
>>> On 30 June 2016 at 06:56, Alexander Shishkin
>>> wrote:
>>>> Currently, there's no runtime pm in stm class devices, which mak
Chunyan Zhang writes:
> On Thu, Jun 30, 2016 at 8:56 PM, Alexander Shishkin
> wrote:
>> There's a kerneldoc comment that'd been derived from another one by way
>> of copying-and-pasting but hadn't been subsequently amended to replect
>
>
Mathieu Poirier writes:
> On 30 June 2016 at 06:56, Alexander Shishkin
> wrote:
>> Currently, there's no runtime pm in stm class devices, which makes it
>> harder for the underlying hardware drivers to handle their power
>> management.
>>
>> This patch a
;output' type device is
in use while a capture is active; the 'source' type device (STH) relies
on its child stm class device for runtime pm tracking.
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/intel_th/core.c | 54 ---
drivers/h
'output' type device callbacks are missing from the kerneldoc description
of the 'intel_th_driver' structure. Fix this.
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/intel_th/intel_th.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hwtracing/in
this update, but
from the code I concluded that its driver keeps it 'active' the entire
time it's enabled, so this update shouldn't make a difference for
it. However, this stm class update should allow for more fine-grained
runtime pm for coresight-stm as well in the future.
Alex
There's a kerneldoc comment that'd been derived from another one by way
of copying-and-pasting but hadn't been subsequently amended to replect
the purpose of the function. Fix this.
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/intel_th/gth.c | 2 +-
1 file changed, 1
cking:
* device is in use during character device writes,
* delayed autosuspend is used to keep it active between adjacent
writes,
* device is in use while mmio regions are mapped,
* device is is use while any stm_source devices are linked to it.
Signed-off-by: Alexander Shishkin
Cc: Mathieu Po
This adds Intel(R) Trace Hub PCI ID for Kaby Lake PCH-H.
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/intel_th/pci.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/hwtracing/intel_th/pci.c b/drivers/hwtracing/intel_th/pci.c
index 5e25c7eb31..0bba384233 100644
--- a
Hi Greg,
Here's a fix to one annoying bug in the driver initialization and a
new PCI ID that I'd like to get into 4.7 and probably -stable. I'm
going to request-pull it to you unless somebody objects.
Alexander Shishkin (2):
intel_th: Fix a deadlock in modprobing
intel_th: pci
Driver initialization tries to request a hub (GTH) driver module from
its probe callback, resulting in a deadlock.
This patch solves the problem by adding a deferred work for requesting
the hub module.
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/intel_th/core.c | 35
[adding Felipe for his sudden interest in the subject matter]
Chunyan Zhang writes:
> +static struct stm_ftrace *trace_output;
What you want is a possibility to have different ftrace outputs, not
different STM outputs for ftrace (again, STM core already does this).
In other words, here, you wan
Ben Hutchings writes:
> When kernel.perf_event_open is set to 3 (or greater), disallow all
> access to performance events by users without CAP_SYS_ADMIN.
> Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> makes this value the default.
So this patch does two things, can it then be
Chunyan Zhang writes:
> On Tue, Jun 7, 2016 at 6:04 PM, Alexander Shishkin
> wrote:
>> Chunyan Zhang writes:
>>
>>> This patch is introducing a new function to print Ftrace messages
>>> to STM buffer when the traces happen. In order to reduce the
>
Commit-ID: 62a92c8f553e49270a0ee391b8733da71ab0aebc
Gitweb: http://git.kernel.org/tip/62a92c8f553e49270a0ee391b8733da71ab0aebc
Author: Alexander Shishkin
AuthorDate: Tue, 7 Jun 2016 15:44:15 +0300
Committer: Ingo Molnar
CommitDate: Wed, 8 Jun 2016 14:30:01 +0200
perf/core: Remove a
Chunyan Zhang writes:
> On Tue, Jun 7, 2016 at 6:25 PM, Alexander Shishkin
> wrote:
>> Chunyan Zhang writes:
>>
>>> This patch adds a driver that models itself as an stm_source and
>>> who's sole purpose is to export an interface to the rest of the
>
::pmu==NULL situation in _free_event() and confuses the robots.
This patch gets rid of the check.
Signed-off-by: Alexander Shishkin
Reported-by: Dan Carpenter
---
kernel/events/core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/c
Chunyan Zhang writes:
> This patchset is an RFC aimed at generating ideas on the best way to
> use STM IP blocks to collect function tracing information produced by
> Ftrace. That way logging information generated by the function trace
> subsystem and gathered in the coresight sink can be used i
Chunyan Zhang writes:
> This patch adds a driver that models itself as an stm_source and
> who's sole purpose is to export an interface to the rest of the
> kernel. Once the stm and stm_source have been linked via sysfs,
> everything that is passed to the interface will endup in the STM
> trace
Chunyan Zhang writes:
> This patch is introducing a new function to print Ftrace messages
> to STM buffer when the traces happen. In order to reduce the
> effect on timing overhead as much as possible, only the current
> function and its parent ip address will be recorded into STM in
> this patc
Chunyan Zhang writes:
> This patch adds an output from Ftrace to STM.
But does it?
> That being said,
> Function trace messages would also be duplicated to STM buffer when
> being stored into ring buffer.
Not sure what you mean here. What's "STM buffer"?
>
> Signed-off-by: Chunyan Zhang
> --
tip-bot for Alexander Shishkin writes:
> Commit-ID: ab92b232ae05c382c3df0e3d6a5c6d16b639ac8c
> Gitweb: http://git.kernel.org/tip/ab92b232ae05c382c3df0e3d6a5c6d16b639ac8c
> Author: Alexander Shishkin
> AuthorDate: Tue, 10 May 2016 16:18:32 +0300
> Committer: Ingo Molna
Ingo Molnar writes:
> * Alexander Shishkin wrote:
>
>> tip-bot for Alexander Shishkin writes:
>>
>> > Commit-ID: 5fbe4788b55540a6c4fe2c47e05482ac356eaf74
>> > Gitweb:
>> > http://git.kernel.org/tip/5fbe4788b55540a6c4fe2c47e05482a
Commit-ID: ab92b232ae05c382c3df0e3d6a5c6d16b639ac8c
Gitweb: http://git.kernel.org/tip/ab92b232ae05c382c3df0e3d6a5c6d16b639ac8c
Author: Alexander Shishkin
AuthorDate: Tue, 10 May 2016 16:18:32 +0300
Committer: Ingo Molnar
CommitDate: Thu, 12 May 2016 14:45:59 +0200
perf/x86/intel/pt
Commit-ID: 9f448cd3cbcec8995935e60b27802ae56aac8cc0
Gitweb: http://git.kernel.org/tip/9f448cd3cbcec8995935e60b27802ae56aac8cc0
Author: Alexander Shishkin
AuthorDate: Tue, 10 May 2016 16:18:33 +0300
Committer: Ingo Molnar
CommitDate: Thu, 12 May 2016 14:46:11 +0200
perf/core: Disable
tip-bot for Alexander Shishkin writes:
> Commit-ID: 5fbe4788b55540a6c4fe2c47e05482ac356eaf74
> Gitweb: http://git.kernel.org/tip/5fbe4788b55540a6c4fe2c47e05482ac356eaf74
> Author: Alexander Shishkin
> AuthorDate: Tue, 10 May 2016 16:18:32 +0300
> Committer: Ingo Molna
Commit-ID: 3f56e687a138481894a1088d5aa7d41951bdb020
Gitweb: http://git.kernel.org/tip/3f56e687a138481894a1088d5aa7d41951bdb020
Author: Alexander Shishkin
AuthorDate: Tue, 10 May 2016 16:18:33 +0300
Committer: Ingo Molnar
CommitDate: Thu, 12 May 2016 10:14:55 +0200
perf/core: Disable
Commit-ID: 5fbe4788b55540a6c4fe2c47e05482ac356eaf74
Gitweb: http://git.kernel.org/tip/5fbe4788b55540a6c4fe2c47e05482ac356eaf74
Author: Alexander Shishkin
AuthorDate: Tue, 10 May 2016 16:18:32 +0300
Committer: Ingo Molnar
CommitDate: Thu, 12 May 2016 10:14:55 +0200
perf/x86/intel/pt
Peter Zijlstra writes:
> On Wed, May 11, 2016 at 12:41:27PM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra writes:
>> >
>> > Does the userspace tool know how to deal with this and re-enable it?
>>
>> Yes, it knows to ioctl(EVENT_ENABLE). Also, we&#x
Peter Zijlstra writes:
> On Tue, May 10, 2016 at 04:18:33PM +0300, Alexander Shishkin wrote:
>> When the PMU driver reports a truncated AUX record, it effectively means
>> that there is no more usable room in the event's AUX buffer (even though
>> there may s
event and waking up the consumer in case of a
truncated AUX record.
Reported-by: Markus Metzger
Signed-off-by: Alexander Shishkin
---
kernel/events/ring_buffer.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buff
generate a PMI when the last output region is
full.
Reported-by: Markus Metzger
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 5b648d4a94..a157cf67a9 100644
--- a/arch
Hence two patches. I propose to put these through perf/urgent and also
stable trees so that people with older kernels still get to collect
humongous amounts of PT traces in cpu-wide mode.
Alexander Shishkin (2):
perf/x86/intel/pt: Generate PMI in the STOP region as well
perf: Disable the event on a
601 - 700 of 1531 matches
Mail list logo
