Re: [perf] perf_fuzzer causes unchecked MSR access error

On Wed, 3 Mar 2021, Liang, Kan wrote: > We never use bit 58. It should be a new issue. > Is it repeatable? yes, it's repeatable. (which I'm glad to see because it looks suspiciously like a memory bit flip) Though since it's a WARN_ONCE I have to reboot each time I want to test. If I get a

[perf] perf_fuzzer causes unchecked MSR access error

Hello on my Haswell machine the perf_fuzzer managed to trigger this message: [117248.075892] unchecked MSR access error: WRMSR to 0x3f1 (tried to write 0x0400) at rIP: 0x8106e4f4 (native_write_msr+0x4/0x20) [117248.089957] Call Trace: [117248.092685]

Re: [perf] perf_fuzzer causes crash in intel_pmu_drain_pebs_nhm()

On Mon, 1 Mar 2021, Liang, Kan wrote: > https://lore.kernel.org/lkml/tip-01330d7288e0050c5aaabc558059ff91589e6...@git.kernel.org/ > The patch is an SW workaround for some old CPUs (HSW and earlier), which may > set 0 to the PEBS status. It adds a check in the intel_pmu_drain_pebs_nhm(). > It

Re: [perf] perf_fuzzer causes crash in intel_pmu_drain_pebs_nhm()

On Thu, 11 Feb 2021, Liang, Kan wrote: > > On Thu, Jan 28, 2021 at 02:49:47PM -0500, Vince Weaver wrote: > I'd like to reproduce it on my machine. > Is this issue only found in a Haswell client machine? > > To reproduce the issue, can I use ./perf_fuzzer under perf_event_te

Re: [perf] perf_fuzzer causes crash in intel_pmu_drain_pebs_nhm()

On Thu, 28 Jan 2021, Vince Weaver wrote: > the perf_fuzzer has turned up a repeatable crash on my haswell system. > > addr2line is not being very helpful, it points to DECLARE_PER_CPU_FIRST. > I'll investigate more when I have the chance. so I poked around some more. This seems

[perf] perf_fuzzer causes crash in intel_pmu_drain_pebs_nhm()

Hello the perf_fuzzer has turned up a repeatable crash on my haswell system. addr2line is not being very helpful, it points to DECLARE_PER_CPU_FIRST. I'll investigate more when I have the chance. Vince [96289.009646] BUG: kernel NULL pointer dereference, address: 0150

Re: [patch] perf tool buffer overflow in perf_header__read_build_ids

On Fri, 26 Jul 2019, Arnaldo Carvalho de Melo wrote: > Em Tue, Jul 23, 2019 at 04:42:30PM -0400, Vince Weaver escreveu: > > my perf_tool_fuzzer has found another issue, this one a buffer overflow > > in perf_header__read_build_ids. The build id filename is read in with a >

[tip:perf/core] perf.data documentation: Clarify HEADER_SAMPLE_TOPOLOGY format

Commit-ID: 3143906c2770778d89b730e0342b745d1b4a8303 Gitweb: https://git.kernel.org/tip/3143906c2770778d89b730e0342b745d1b4a8303 Author: Vince Weaver AuthorDate: Thu, 1 Aug 2019 14:30:43 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 14 Aug 2019 10:59:59 -0300 perf.data

[patch] perf.data documentation clarify HEADER_SAMPLE_TOPOLOGY format

The perf.data file format documentation for HEADER_SAMPLE_TOPOLOGY specifies the layout in a confusing manner that doesn't match the rest of the document. This patch attempts to describe things consistent with the rest of the file. Signed-off-by: Vince Weaver diff --git a/tools/perf

[tip:perf/urgent] perf tools: Fix perf.data documentation units for memory size

Commit-ID: 2e9a06dda10aea81a17c623f08534dac6735434a Gitweb: https://git.kernel.org/tip/2e9a06dda10aea81a17c623f08534dac6735434a Author: Vince Weaver AuthorDate: Thu, 25 Jul 2019 11:57:43 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 29 Jul 2019 09:03:43 -0300 perf tools

[tip:perf/urgent] perf header: Fix divide by zero error if f_header.attr_size==0

Commit-ID: 7622236ceb167aa3857395f9bdaf871442aa467e Gitweb: https://git.kernel.org/tip/7622236ceb167aa3857395f9bdaf871442aa467e Author: Vince Weaver AuthorDate: Tue, 23 Jul 2019 11:06:01 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 29 Jul 2019 09:03:43 -0300 perf header

Re: perf: perf report stuck in an infinite loop

On Fri, 26 Jul 2019, Arnaldo Carvalho de Melo wrote: > Em Fri, Jul 26, 2019 at 04:46:51PM -0400, Vince Weaver escreveu: > > > > Currently the perf_data_fuzzer causes perf report to get stuck in an > > infinite loop. > > > > >From what I can tell, the iss

perf: perf report stuck in an infinite loop

Currently the perf_data_fuzzer causes perf report to get stuck in an infinite loop. >From what I can tell, the issue happens in reader__process_events() when an event is mapped using mmap(), but when it goes to process the event finds out the internal event header has the size (invalidly) set

Re: [patch] perf report segfault with 0-sized strings

probably all perf_header_strings are affected by this. The fuzzer just tripped up cmdline now, which needs this fix. Signed-off-by: Vince Weaver diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c index c24db7f4909c..631aa1911f3a 100644 --- a/tools/perf/util/header.c +++ b

[patch] perf report segfault with 0-sized strings

Hello, the perf_data_fuzzer found an issue when strings have size 0. malloc() in do_read_string() is happy to allocate a string of size 0 but when code (in this case the pmu parser) tries to work with those it will segfault. Signed-off-by: Vince Weaver diff --git a/tools/perf/util/header.c b

[patch] perf.data documentation has wrong units for memory size

The perf.data-file-format documentation incorrectly says the HEADER_TOTAL_MEM results are in bytes. The results are in kilobytes (perf reads the value from /proc/meminfo) Signed-off-by: Vince Weaver diff --git a/tools/perf/Documentation/perf.data-file-format.txt b/tools/perf/Documentation

[patch] perf tool buffer overflow in perf_header__read_build_ids

, not sure if filename should be NUL terminated or not. Signed-off-by: Vince Weaver diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c index c24db7f4909c..9a893a26e678 100644 --- a/tools/perf/util/header.c +++ b/tools/perf/util/header.c @@ -2001,6 +2001,9 @@ static int

[patch] perf tool divide by zero error if f_header.attr_size==0

Hello so I have been having lots of trouble with hand-crafted perf.data files causing segfaults and the like, so I have started fuzzing the perf tool. First issue found: If f_header.attr_size is 0 in the perf.data file, then perf will crash with a divide-by-zero error. Signed-off-by: Vince

Re: WARNING in perf_reg_value

On Wed, 19 Jun 2019, syzbot wrote: > syzbot found the following crash on: > > HEAD commit:0011572c Merge branch 'for-5.2-fixes' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=12c38d66a0 > kernel config:

Re: [PATCH V2 1/3] perf/x86: Disable non generic regs for software/probe events

On Tue, 28 May 2019, Peter Zijlstra wrote: > On Tue, May 28, 2019 at 09:33:40AM -0400, Liang, Kan wrote: > > Uncore PMU doesn't support sampling. It will return -EINVAL. > > There is no regs support for counting. The request will be ignored. > > > > I think current check for uncore is good

Re: [PATCH 1/2] perf/x86: Disable non generic regs for software/probe events

I've run the fuzzer overnight with both patches applied and have not seen any issues. Vince

Re: perf: fuzzer causes crash in new XMM code

On Wed, 22 May 2019, Liang, Kan wrote: > XMM registers can only collected by hardware PEBS events. We should disable it > for all software/probe events. > > Could you please try the patch as below? I tested the patch (it was whitespace damaged for some reason, not sure if that was on my end

perf: fuzzer causes crash in new XMM code

The perf fuzzer caused my skylake machine to crash hard with the trace at the end here. (this is with current git) It appears to be happening in new code introduced by: commit 878068ea270ea82767ff1d26c91583263c81fba0 Author: Kan Liang Date: Tue Apr 2 12:44:59 2019 -0700 perf/x86:

Re: [tip:perf/core] perf/x86/intel: Force resched when TFA sysctl is modified

On Tue, 16 Apr 2019, tip-bot for Stephane Eranian wrote: > Commit-ID: f447e4eb3ad1e60d173ca997fcb2ef2a66f12574 > Gitweb: > https://git.kernel.org/tip/f447e4eb3ad1e60d173ca997fcb2ef2a66f12574 > Author: Stephane Eranian > AuthorDate: Mon, 8 Apr 2019 10:32:52 -0700 > Committer: Ingo

Re: perf: perf_fuzzer crashes on Pentium 4 systems

On Sun, 7 Apr 2019, Cyrill Gorcunov wrote: > Vince, could you please disable alias events and see if it change > anything, once you have time? Note once we've aliases disabled the > counter for cpu cycles get used for NMI watchdog so PERF_COUNT_HW_CPU_CYCLES > won't be available in "perf" tool

Re: perf: perf_fuzzer crashes on Pentium 4 systems

On Thu, 4 Apr 2019, Cyrill Gorcunov wrote: > On Thu, Apr 04, 2019 at 12:37:18PM -0400, Vince Weaver wrote: > > Oh, Vince, I suspect such kind of bisection might consume a lot of your > time :( Maybe we could update perf fuzzer so that it would send events > to some net-storage f

Re: perf: perf_fuzzer crashes on Pentium 4 systems

On Thu, 4 Apr 2019, Cyrill Gorcunov wrote: > On Thu, Apr 04, 2019 at 09:25:47AM -0400, Vince Weaver wrote: > > > > It looks like there are at least two bugs here, one that's a full > > hardlockup with nothing on serial console. The other is the NULL > > dereference.

Re: perf: perf_fuzzer crashes on Pentium 4 systems

On Wed, 3 Apr 2019, Cyrill Gorcunov wrote: > On Wed, Apr 03, 2019 at 10:19:44PM +0300, Cyrill Gorcunov wrote: > > > > You know, seems I got what happened -- p4_general_events do > > not cover all general events, they stop at PERF_COUNT_HW_BUS_CYCLES, > > while more 3 general event left. This is

perf: perf_fuzzer crashes on Pentium 4 systems

so moving this to its own thread. There was a two-part question asked. 1. Can the perf-fuzzer crash a Pentium 4 system 2. Does anyone care anymore? The answer to #1 turns out to be "yes" I'm not sure about #2 (but it's telling my p4 test system hadn't been turned on in over 3

Re: [RFC PATCH v3 0/3] x86/perf/amd: AMD PMC counters and NMI latency

On Wed, 3 Apr 2019, Cyrill Gorcunov wrote: > > Shame on Intel though for not providing perf JSON files for the > > Pentium 4 event names. > > Mind to point me where json events should lay, I could try to convert > names. I was mostly joking about that. But the event lists are in the kernel

Re: [tip:perf/urgent] perf/x86/intel: Initialize TFA MSR

gt; > Cc: Arnaldo Carvalho de Melo > > Cc: Jiri Olsa > > Cc: Linus Torvalds > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Vince Weaver > > Cc: to...@suse.com > > Link: > > https://lkml.kernel.org/r/20190321123849.gn6...@hirez.programmi

Re: [RFC PATCH v3 0/3] x86/perf/amd: AMD PMC counters and NMI latency

On Tue, 2 Apr 2019, Cyrill Gorcunov wrote: > You know, running fuzzer on p4 might worth in anycase. As to potential > problems to fix -- i could try find some time slot for, still quite > limited too 'cause of many other duties :( Well I fired up the Pentium 4 /dev/sda1 has gone 1457

Re: [RFC PATCH v3 0/3] x86/perf/amd: AMD PMC counters and NMI latency

On Tue, 2 Apr 2019, Cyrill Gorcunov wrote: > On Tue, Apr 02, 2019 at 03:03:02PM +0200, Peter Zijlstra wrote: > > I have vague memories of the P4 thing crashing with Vince's perf_fuzzer, > > but maybe I'm wrong. > > No, you're correct. p4 was crashing many times before we manage to make > it

Re: System crash with perf_fuzzer (kernel: 5.0.0-rc3)

On Fri, 1 Feb 2019, Jiri Olsa wrote: > > > > I've just started fuzzing with the patch applied. Often it takes a few > > hours to trigger the bug. > > cool, thanks I let it run overnight and no crash. > > Added question about this bug. It appeared that the crash was triggered > > by the

Re: System crash with perf_fuzzer (kernel: 5.0.0-rc3)

crash was triggered by the BTS driver over-writing kernel memory. The data being written, was this user controllable? Meaning, is this a security issue being fixed, or just a crashing issue? Vince Weaver vincent.wea...@maine.edu

Re: System crash with perf_fuzzer (kernel: 5.0.0-rc3)

On Fri, 25 Jan 2019, Ravi Bangoria wrote: > I'm seeing a system crash while running perf_fuzzer with upstream kernel > on an Intel machine. I hit the crash twice (out of which I don't have log > of first crash so don't know if the reason is same for both the crashes). > I've attached my .config

Re: perf: rdpmc bug when viewing all procs on remote cpu

On Fri, 18 Jan 2019, Peter Zijlstra wrote: > > You can actually use rdpmc when you attach to a CPU, but you have to > ensure that the userspace component is guaranteed to run on that very > CPU (sched_setaffinity(2) comes to mind). unfortunately the HPC people using PAPI would probably be

Re: perf: rdpmc bug when viewing all procs on remote cpu

On Fri, 18 Jan 2019, Peter Zijlstra wrote: > On Fri, Jan 11, 2019 at 04:52:22PM -0500, Vince Weaver wrote: > > On Thu, 10 Jan 2019, Vince Weaver wrote: > > > > > On Thu, 10 Jan 2019, Vince Weaver wrote: > > > > > > > On Thu, 10 Jan 2019, Vince We

Re: perf: rdpmc bug when viewing all procs on remote cpu

On Thu, 10 Jan 2019, Vince Weaver wrote: > On Thu, 10 Jan 2019, Vince Weaver wrote: > > > On Thu, 10 Jan 2019, Vince Weaver wrote: > > > > > However if you create an all-process attached to CPU event: > > > perf_event_open(attr, -1, X, -1, 0); > > >

Re: perf: rdpmc bug when viewing all procs on remote cpu

On Thu, 10 Jan 2019, Vince Weaver wrote: > On Thu, 10 Jan 2019, Vince Weaver wrote: > > > However if you create an all-process attached to CPU event: > > perf_event_open(attr, -1, X, -1, 0); > > the mmap event index is set as if this were a valid event and so the

Re: perf: rdpmc bug when viewing all procs on remote cpu

On Thu, 10 Jan 2019, Vince Weaver wrote: > However if you create an all-process attached to CPU event: > perf_event_open(attr, -1, X, -1, 0); > the mmap event index is set as if this were a valid event and so the rdpmc > succeeds even though it shouldn't (we're trying to read an

perf: rdpmc bug when viewing all procs on remote cpu

Hello I think this is a bug turned up by PAPI. I've been trying to track down where this happens in the perf_event code myself, but it might be faster to just report it. If you create a per-process attached to CPU event: perf_event_open(attr, 0, X, -1, 0); the mmap event index is set

Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample

On Thu, 6 Dec 2018, Jiri Olsa wrote: > On Thu, Dec 06, 2018 at 10:35:28AM -0500, Vince Weaver wrote: > > On Wed, 5 Dec 2018, Jiri Olsa wrote: > > Maybe it is a corruption issue. I had applied my own debug patch that > > would dump some info if data->callchain was NUL

Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample

On Wed, 5 Dec 2018, Jiri Olsa wrote: > On Wed, Dec 05, 2018 at 12:11:19PM -0500, Vince Weaver wrote: > > On Wed, 5 Dec 2018, Jiri Olsa wrote: > > > > > On Wed, Dec 05, 2018 at 01:45:38PM +0100, Jiri Olsa wrote: > > > > On Tue, Dec 04, 2018 at 10:54:55AM -0500,

Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample

On Wed, 5 Dec 2018, Jiri Olsa wrote: > On Wed, Dec 05, 2018 at 12:11:19PM -0500, Vince Weaver wrote: > > On Wed, 5 Dec 2018, Jiri Olsa wrote: > > > > > On Wed, Dec 05, 2018 at 01:45:38PM +0100, Jiri Olsa wrote: > > > > On Tue, Dec 04, 2018 at 10:54:55AM -0500,

Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample

On Wed, 5 Dec 2018, Jiri Olsa wrote: > On Wed, Dec 05, 2018 at 01:45:38PM +0100, Jiri Olsa wrote: > > On Tue, Dec 04, 2018 at 10:54:55AM -0500, Vince Weaver wrote: > > > Hello, > > > > > > I was able to trigger another oops with the perf_fuzzer with curren

Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample

On Wed, 5 Dec 2018, Jiri Olsa wrote: > On Wed, Dec 05, 2018 at 01:45:38PM +0100, Jiri Olsa wrote: > > On Tue, Dec 04, 2018 at 10:54:55AM -0500, Vince Weaver wrote: > > > Hello, > > > > > > I was able to trigger another oops with the perf_fuzzer with curren

perf: perf_fuzzer triggers GPF in perf_prepare_sample

Hello, I was able to trigger another oops with the perf_fuzzer with current git. This is 4.20-rc5 after the fix for the very similar oops I previously reported got committed. It seems to be pointing to the same location in the source as before, I guess maybe triggered a different way?

perf: perf_fuzzer triggers GPF in perf_prepare_sample

Hello, I was able to trigger another oops with the perf_fuzzer with current git. This is 4.20-rc5 after the fix for the very similar oops I previously reported got committed. It seems to be pointing to the same location in the source as before, I guess maybe triggered a different way?

Re: perf: perf_fuzzer triggers NULL pointer dereference

On Thu, 8 Nov 2018, Alexander Shishkin wrote: > Vince Weaver writes: > > > On Thu, 8 Nov 2018, Vince Weaver wrote: > > > >> [91760.326510] BUG: unable to handle kernel NULL pointer dereference at > >> > >> [91760.334876] PGD 0 P4D 0

Re: perf: perf_fuzzer triggers NULL pointer dereference

On Thu, 8 Nov 2018, Alexander Shishkin wrote: > Vince Weaver writes: > > > On Thu, 8 Nov 2018, Vince Weaver wrote: > > > >> [91760.326510] BUG: unable to handle kernel NULL pointer dereference at > >> > >> [91760.334876] PGD 0 P4D 0

Re: perf: perf_fuzzer triggers NULL pointer dereference

On Thu, 8 Nov 2018, Vince Weaver wrote: > [91760.326510] BUG: unable to handle kernel NULL pointer dereference at > > [91760.334876] PGD 0 P4D 0 > [91760.337596] Oops: [#1] SMP PTI > [91760.341332] CPU: 6 PID: 0 Comm: swapper/6 Tainted: GW

Re: perf: perf_fuzzer triggers NULL pointer dereference

On Thu, 8 Nov 2018, Vince Weaver wrote: > [91760.326510] BUG: unable to handle kernel NULL pointer dereference at > > [91760.334876] PGD 0 P4D 0 > [91760.337596] Oops: [#1] SMP PTI > [91760.341332] CPU: 6 PID: 0 Comm: swapper/6 Tainted: GW

perf: perf_fuzzer triggers NULL pointer dereference

*** by Vince Weaver Linux version 4.20.0-rc1+ x86_64 Processor: Intel 6/60/3 Stopping after 3 Watchdog enabled with timeout 60s Will auto-exit if signal storm detected Seeding RNG from time 1541627285 To reproduce, try

perf: perf_fuzzer triggers NULL pointer dereference

*** by Vince Weaver Linux version 4.20.0-rc1+ x86_64 Processor: Intel 6/60/3 Stopping after 3 Watchdog enabled with timeout 60s Will auto-exit if signal storm detected Seeding RNG from time 1541627285 To reproduce, try

Re: [perf] perf_event.h ABI visibility question

On Mon, 27 Aug 2018, Peter Zijlstra wrote: > Something like so then? > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h > index eeb787b1c53c..f35eb72739c0 100644 > --- a/include/uapi/linux/perf_event.h > +++ b/include/uapi/linux/perf_event.h > @@ -144,7 +144,7 @@

Re: [perf] perf_event.h ABI visibility question

On Mon, 27 Aug 2018, Peter Zijlstra wrote: > Something like so then? > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h > index eeb787b1c53c..f35eb72739c0 100644 > --- a/include/uapi/linux/perf_event.h > +++ b/include/uapi/linux/perf_event.h > @@ -144,7 +144,7 @@

Re: [perf] perf_event.h ABI visibility question

On Fri, 24 Aug 2018, Peter Zijlstra wrote: > > +++ b/include/uapi/linux/perf_event.h > > @@ -143,6 +143,8 @@ enum perf_event_sample_format { > > PERF_SAMPLE_PHYS_ADDR = 1U << 19, > > > > PERF_SAMPLE_MAX = 1U << 20, /* non-ABI */ > > + > > +

Re: [perf] perf_event.h ABI visibility question

On Fri, 24 Aug 2018, Peter Zijlstra wrote: > > +++ b/include/uapi/linux/perf_event.h > > @@ -143,6 +143,8 @@ enum perf_event_sample_format { > > PERF_SAMPLE_PHYS_ADDR = 1U << 19, > > > > PERF_SAMPLE_MAX = 1U << 20, /* non-ABI */ > > + > > +

[perf] perf_event.h ABI visibility question

I notice that Linux 4.18 has the following changeset which changes the user visible perf_event.h file commit 6cbc304f2f360f25cc8607817239d6f4a2fd3dc5 Author: Peter Zijlstra Date: Thu May 10 15:48:41 2018 +0200 perf/x86/intel: Fix unwind errors from PEBS entries

[perf] perf_event.h ABI visibility question

I notice that Linux 4.18 has the following changeset which changes the user visible perf_event.h file commit 6cbc304f2f360f25cc8607817239d6f4a2fd3dc5 Author: Peter Zijlstra Date: Thu May 10 15:48:41 2018 +0200 perf/x86/intel: Fix unwind errors from PEBS entries

Re: [PATCH v3 0/5]

interrupt-parent = <_intc>; interrupts = <9 IRQ_TYPE_LEVEL_HIGH>; }; Tested-by: Vince Weaver <vincent.wea...@maine.edu> Vince

Re: [PATCH v3 0/5]

interrupt-parent = <_intc>; interrupts = <9 IRQ_TYPE_LEVEL_HIGH>; }; Tested-by: Vince Weaver Vince

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Vince Weaver wrote: > On Thu, 17 May 2018, Peter Zijlstra wrote: > with cortex-a7 now, would it be possible to later drop that if proper > cortex-a53 support is added to the armv7 pmu driver? Or would that lead > to all kinds of back-compatability mess? F

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Vince Weaver wrote: > On Thu, 17 May 2018, Peter Zijlstra wrote: > with cortex-a7 now, would it be possible to later drop that if proper > cortex-a53 support is added to the armv7 pmu driver? Or would that lead > to all kinds of back-compatability mess? F

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Peter Zijlstra wrote: > On Thu, May 17, 2018 at 06:55:26PM +0200, Stefan Wahren wrote: > > > Vince Weaver <vincent.wea...@maine.edu> hat am 17. Mai 2018 um 18:34 > > > geschrieben: > > > On Thu, 17 May 2018, Stefan Wahren wrote: > >

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Peter Zijlstra wrote: > On Thu, May 17, 2018 at 06:55:26PM +0200, Stefan Wahren wrote: > > > Vince Weaver hat am 17. Mai 2018 um 18:34 > > > geschrieben: > > > On Thu, 17 May 2018, Stefan Wahren wrote: > > > > &

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Stefan Wahren wrote: > > > Eric Anholt hat am 17. Mai 2018 um 15:17 geschrieben: > > > > > > The a53 and a7 counters seem to match up, so we advertise a7 so that > > arm32 can probe. so how closely did you look at the a53/a7 differences? I see some

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Stefan Wahren wrote: > > > Eric Anholt hat am 17. Mai 2018 um 15:17 geschrieben: > > > > > > The a53 and a7 counters seem to match up, so we advertise a7 so that > > arm32 can probe. so how closely did you look at the a53/a7 differences? I see some major differences,

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Eric Anholt wrote: > > Is that better than a53? I'm happy to switch to that. The important > part to me is the a7, since basically everyone with this hw is running > arm32. no, on further investigation it looks like a53 is more proper to use than the generic armv8. Is

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Eric Anholt wrote: > > Is that better than a53? I'm happy to switch to that. The important > part to me is the a7, since basically everyone with this hw is running > arm32. no, on further investigation it looks like a53 is more proper to use than the generic armv8. Is

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Eric Anholt wrote: > diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi > index 7704bb029605..1f5e5c782835 100644 > --- a/arch/arm/boot/dts/bcm2837.dtsi > +++ b/arch/arm/boot/dts/bcm2837.dtsi > @@ -17,6 +17,12 @@ > }; > }; > > +

Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

On Thu, 17 May 2018, Eric Anholt wrote: > diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi > index 7704bb029605..1f5e5c782835 100644 > --- a/arch/arm/boot/dts/bcm2837.dtsi > +++ b/arch/arm/boot/dts/bcm2837.dtsi > @@ -17,6 +17,12 @@ > }; > }; > > +

Re: perf: fuzzer causes stack going in wrong direction warnings

On Fri, 4 May 2018, Josh Poimboeuf wrote: > > The 'nmi_restore' warning points to a bug in my patch, but the others > are head scratchers. Here's a patch which combines the first two > patches, plus improves the existing warnings a bit. Can you try it? with that updated patch I hit May 4

Re: perf: fuzzer causes stack going in wrong direction warnings

On Fri, 4 May 2018, Josh Poimboeuf wrote: > > The 'nmi_restore' warning points to a bug in my patch, but the others > are head scratchers. Here's a patch which combines the first two > patches, plus improves the existing warnings a bit. Can you try it? with that updated patch I hit May 4

Re: perf: fuzzer causes stack going in wrong direction warnings

On Fri, 4 May 2018, Josh Poimboeuf wrote: > Also, any tips for reproducing this locally? I cloned the perf fuzzer > github. Is it as simple as just "make" and "./run_tests.sh"? run_tests only runs the perf_event regressiong tests. To run the fuzzer, enter the "fuzzer" directory and either run

Re: perf: fuzzer causes stack going in wrong direction warnings

On Fri, 4 May 2018, Josh Poimboeuf wrote: > Also, any tips for reproducing this locally? I cloned the perf fuzzer > github. Is it as simple as just "make" and "./run_tests.sh"? run_tests only runs the perf_event regressiong tests. To run the fuzzer, enter the "fuzzer" directory and either run

Re: perf: fuzzer causes stack going in wrong direction warnings

On Wed, 2 May 2018, Josh Poimboeuf wrote: > After looking closer, I realized that at least some of these warnings > are due to bad unwind hints in the entry code. Can you try this patch > instead of the last one? with just this new patch applied I still get warnings such as this: [

Re: perf: fuzzer causes stack going in wrong direction warnings

On Wed, 2 May 2018, Josh Poimboeuf wrote: > After looking closer, I realized that at least some of these warnings > are due to bad unwind hints in the entry code. Can you try this patch > instead of the last one? with just this new patch applied I still get warnings such as this: [

Re: perf: fuzzer causes stack going in wrong direction warnings

On Tue, 1 May 2018, Josh Poimboeuf wrote: > Can you try the following patch? I applied the patch, but the warnings don't really look that different. [ 62.220322] WARNING: stack recursion on stack type 4 [ 62.220326] WARNING: can't dereference registers at 9ca2e86d for ip

Re: perf: fuzzer causes stack going in wrong direction warnings

On Tue, 1 May 2018, Josh Poimboeuf wrote: > Can you try the following patch? I applied the patch, but the warnings don't really look that different. [ 62.220322] WARNING: stack recursion on stack type 4 [ 62.220326] WARNING: can't dereference registers at 9ca2e86d for ip

perf: fuzzer causes stack going in wrong direction warnings

Hello I reported this back in January, but I think it got lost since everyone was busy with other more pressing matters. But in any case, the perf_fuzzer still can trigger these type of messages and just wanted to see if they were a cause for concern, or just noise. [66620.496076] WARNING:

perf: fuzzer causes stack going in wrong direction warnings

Hello I reported this back in January, but I think it got lost since everyone was busy with other more pressing matters. But in any case, the perf_fuzzer still can trigger these type of messages and just wanted to see if they were a cause for concern, or just noise. [66620.496076] WARNING:

Re: [RFC] perf/core: what is exclude_idle supposed to do

On Fri, 20 Apr 2018, Vince Weaver wrote: > > AFAICT it works on Power and possibly ARM. > > at least some ARMs are a bit more honest about it than x86 > > ivybridge: > Performance counter stats for '/bin/ls': > 1,368,162 instructions > 1,

Re: [RFC] perf/core: what is exclude_idle supposed to do

On Fri, 20 Apr 2018, Vince Weaver wrote: > > AFAICT it works on Power and possibly ARM. > > at least some ARMs are a bit more honest about it than x86 > > ivybridge: > Performance counter stats for '/bin/ls': > 1,368,162 instructions > 1,

Re: [RFC] perf/core: what is exclude_idle supposed to do

On Fri, 20 Apr 2018, Peter Zijlstra wrote: > On Wed, Apr 18, 2018 at 11:10:20AM -0400, Vince Weaver wrote: > > On Tue, 17 Apr 2018, Jiri Olsa wrote: > > > > > On Mon, Apr 16, 2018 at 10:04:53PM +, Stephane Eranian wrote: > > > > Hi, > > &

Re: [RFC] perf/core: what is exclude_idle supposed to do

On Fri, 20 Apr 2018, Peter Zijlstra wrote: > On Wed, Apr 18, 2018 at 11:10:20AM -0400, Vince Weaver wrote: > > On Tue, 17 Apr 2018, Jiri Olsa wrote: > > > > > On Mon, Apr 16, 2018 at 10:04:53PM +, Stephane Eranian wrote: > > > > Hi, > > &

Re: [RFC] perf/core: what is exclude_idle supposed to do

On Tue, 17 Apr 2018, Jiri Olsa wrote: > On Mon, Apr 16, 2018 at 10:04:53PM +, Stephane Eranian wrote: > > Hi, > > > > I am trying to understand what the exclude_idle event attribute is supposed > > to accomplish. > > As per the definition in the header file: > > > > exclude_idle : 1,

Re: [RFC] perf/core: what is exclude_idle supposed to do

On Tue, 17 Apr 2018, Jiri Olsa wrote: > On Mon, Apr 16, 2018 at 10:04:53PM +, Stephane Eranian wrote: > > Hi, > > > > I am trying to understand what the exclude_idle event attribute is supposed > > to accomplish. > > As per the definition in the header file: > > > > exclude_idle : 1,

perf: fuzzer leads to trace_kprobe: Could not insert message flood

Author: Song Liu Date: Wed Dec 6 14:45:15 2017 -0800 When running the perf_fuzzer on a current git checkout my logs are flooded with messages such as this: [71487.869077] trace_kprobe: Could not insert probe at unknown+0: -22 [71488.174479] trace_kprobe: Could not

perf: fuzzer leads to trace_kprobe: Could not insert message flood

Author: Song Liu Date: Wed Dec 6 14:45:15 2017 -0800 When running the perf_fuzzer on a current git checkout my logs are flooded with messages such as this: [71487.869077] trace_kprobe: Could not insert probe at unknown+0: -22 [71488.174479] trace_kprobe: Could not insert probe at unknown+0:

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

On Fri, 9 Mar 2018, Peter Zijlstra wrote: > On Fri, Mar 09, 2018 at 09:31:11AM -0500, Vince Weaver wrote: > > On Fri, 9 Mar 2018, tip-bot for Kan Liang wrote: > > > > > Commit-ID: 1af22eba248efe2de25658041a80a3d40fb3e92e > > > Gitweb:

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

On Fri, 9 Mar 2018, Peter Zijlstra wrote: > On Fri, Mar 09, 2018 at 09:31:11AM -0500, Vince Weaver wrote: > > On Fri, 9 Mar 2018, tip-bot for Kan Liang wrote: > > > > > Commit-ID: 1af22eba248efe2de25658041a80a3d40fb3e92e > > > Gitweb:

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

Cc: Alexander Shishkin <alexander.shish...@linux.intel.com> > Cc: Arnaldo Carvalho de Melo <a...@redhat.com> > Cc: Jiri Olsa <jo...@redhat.com> > Cc: Linus Torvalds <torva...@linux-foundation.org> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Stephane Eran

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

t threshold is 1, in which > case user-space RDPMC works well even with auto-reload events. > > Signed-off-by: Kan Liang > Signed-off-by: Peter Zijlstra (Intel) > Cc: Alexander Shishkin > Cc: Arnaldo Carvalho de Melo > Cc: Jiri Olsa > Cc: Linus Torvalds > Cc: Peter Zij

Re: perf: perf_fuzzer quickly locks up on 4.15-rc7

On Thu, 11 Jan 2018, Peter Zijlstra wrote: > It makes my IVB very ill, starts spewing RCU stall warnings, but is > otherwise very unresponsive. > > Awesome... I'll prod at it when my brain works again. > Not sure if it's related, but I hit this on the core2 machine fuzzing overnight with

Re: perf: perf_fuzzer quickly locks up on 4.15-rc7

On Thu, 11 Jan 2018, Peter Zijlstra wrote: > It makes my IVB very ill, starts spewing RCU stall warnings, but is > otherwise very unresponsive. > > Awesome... I'll prod at it when my brain works again. > Not sure if it's related, but I hit this on the core2 machine fuzzing overnight with

Re: perf: perf_fuzzer quickly locks up on 4.15-rc7

On Thu, 11 Jan 2018, Vince Weaver wrote: > On Thu, 11 Jan 2018, Peter Zijlstra wrote: > > > On Thu, Jan 11, 2018 at 01:21:12PM -0600, Josh Poimboeuf wrote: > > > Yuck. This time it was stack recursion on the entry stack. In the > > > previous error, recursion

Re: perf: perf_fuzzer quickly locks up on 4.15-rc7

On Thu, 11 Jan 2018, Vince Weaver wrote: > On Thu, 11 Jan 2018, Peter Zijlstra wrote: > > > On Thu, Jan 11, 2018 at 01:21:12PM -0600, Josh Poimboeuf wrote: > > > Yuck. This time it was stack recursion on the entry stack. In the > > > previous error, recursion

Re: perf: perf_fuzzer quickly locks up on 4.15-rc7

On Thu, 11 Jan 2018, Vince Weaver wrote: > Not sure if this info helps, but if I make perf_fuzzer *not* create AUX > mmap() buffers, I'm unable to reproduce the hangs both on core2 and > haswell. Confirmed, I can crash the system without the fuzzer, just by doing perf rec

  1   2   3   4   5   6   7   8   9   10   >