to test.
If I get a chance I'll try to come up with a reduced test case but
probably won't have time for that today.
Vince
MSR 0x3f1 is MSR_IA32_PEBS_ENABLE
this is on recent-git with the patch causing the pebs-related crash
reverted.
Vince
u please revert the patch and check whether it fixes your issue?
I've reverted that patch and my test-case no longer triggers the issue.
I'll restart a longer fuzzing run to see if any other issues turn up.
Thanks,
Vince
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_eve
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 seem
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
[96289.0
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
>
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
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
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
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
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
going on here.
Vince
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
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
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
, 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
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
roducer: https://syzkaller.appspot.com/x/repro.c?x=10e6c876a0
the perf_fuzzer found this issue about a month ago, and patches were
posted that fixed the issue (I've been unable to reproduce when running
with a patched kernel).
Any reason they haven't been applied?
Vince
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 enough
I've run the fuzzer overnight with both patches applied and have not seen
any issues.
Vince
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 tho
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: Supp
; Committer: Ingo Molnar
> CommitDate: Tue, 16 Apr 2019 12:19:35 +0200
>
> perf/x86/intel: Force resched when TFA sysctl is modified
What's TFA? Tuna-fish-alarm? Nowhere in the commit or in the code does
it ever say what a TFA is or why we'd want to resched when it is modified.
Vince
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 av
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
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
> > derefer
general event left. This is 'cause I've not been following
> > pmu evolution in code. I will try to cover this events hopefully more
> > less soon and send you a patch to test (if you don't mind).
>
> Still this should not cause nil deref, continue investigating. V
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 y
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
tr
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
while it's hit a few
WARNINGs and some NMI dazed+confused messages it hasn't actually crashed
yet. Not sure if I want to let it fuzz overnight if I'm not here though.
Shame on Intel though for not providing perf JSON files for the
Pentium 4 event names.
Vince
this
doesn't necessarily apply to the p4.
I do think the number of people trying to run perf on a p4 is probably
pretty small these days.
Vince
I mean: the crash is happening because data structures are getting
over-written by the BTS driver. Depending who and what is doing this,
this could be a security issue (i.e. if it was raw BTS data that was
partially userspace controlled values). Though even if this were the case
it would probably be hard to exploit.
Vince
t the 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
can trigger
with the perf_fuzzer, even as a normal user. I reported it a few months
ago but I don't think it ever got resolved. The traces you get look
similar to some that you posted.
It's hard to track down as it doesn't seem to be a simple issue, but
rather it looks like the BTS event handling is stomping over memory it
shouldn't somehow.
Vince
nature of rdpmc.
If the answer is simply this is the way the kernel is going to do it,
that's fine, I just have to add workarounds to PAPI and then get the
perf_even_open() manpage updated to make sure people are aware of the
issue.
Vince
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
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);
> > >
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
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
nd so the rdpmc
succeeds even though it shouldn't (we're trying to read an event value
on a remote cpu with a local rdpmc).
so I think somehow in the perf_event_open pid=-1 case rdpmc is not getting
blocked properly...
Vince
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
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,
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
f_callchain(event, regs);
>>>>>>>>> size += data->callchain->nr;
header->size += size * sizeof(u64);
}
Vince
[45050.698745] general protection fault: [#1] SMP PTI
[45050.698745] CPU: 5 PID: 13475 Comm: perf_fuzzer Tainted: G
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
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
I was able to trigger this oops with the perf_fuzzer with current git.
I can reliably trigger this on my Haswell machine.
I haven't done any analysis yet, I might not have time to today, but I
wanted to report it in case the cause was obvious to someone else.
Vince
*** perf_fuzzer 0.3
-Original Message-
From: Thor Thayer
Sent: Friday, October 12, 2018 3:49 PM
To: Greg KH
Cc: geert+rene...@glider.be; jho...@kernel.org; at...@kernel.org;
bhelg...@google.com; james.hart...@sondrel.com; linux-kernel@vger.kernel.org;
Bridgers, Vince
Subject: Re: [PATCH] MAINTAINERS
y the purpose of an addition can be a lot of work
sometimes.
Vince
um from 32 to 64 bits on
32-bit machines, though that only really matters if the user is doing
something really weird with enum variables.
Vince
EARLY the value is still in the user-visible
header so it's now part of the ABI and I guess the manpage has to document it.
Vince
interrupt-parent = <&local_intc>;
interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
};
Tested-by: Vince Weaver
Vince
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
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:
> > > > &
s? I see some major
differences, especially with the CPU_CYCLES event (0xff vs 0x11).
The proper fix here might be to add a cortex-a53 PMU entry to the armv7
code rather than trying to treat it as a cortex-a7.
Vince
eneric armv8.
Is the armv8 pmu on the cortex-a53 backwards compatible with armv7? I'm
dreading having to pull up the various ARM ARMs to look for myself so if
it works for you I'm fine with that part too.
The biggest pushback I had with my original patch was no one believing irq
9 was the right one to use.
Vince
ot
arm-pmu {
compatible = "arm,armv8-pmuv3";
interrupt-parent = <&local_intc>;
interrupts = <9>;
};
which works, though when I didn't get very far when I submitted the patch
to add this last August.
Vince
housand entries that look mostly similar)
Vince
s the WARNINGs trigger fairly
quickly (within minutes usually).
You might also encounter a handful of other known kernel warnings which
I've reported in the past and usually just ignore.
Vince
;t dereference iret registers at 1754e5aa
for ip nmi_restore+0x16/0x2b
[ 3650.161250] WARNING: missing regs for base reg R10 at ip
native_sched_clock+0xd/0x90
Vince
a2e86d for ip
swapgs_restore_regs_and_return_to_usermode+0x79/0x87
[ 367.597013] WARNING: stack going in the wrong direction?
ip=native_sched_clock+0x9/0x90
Vince
gisters at c8f3c864
for ip error_exit+0x20/0x20
Vince
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
>
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,
> > >
> >
> > exclude_idle : 1, /* don't count when idle */
>
> AFAICS it's not implemented
so just to be completely clear hear, we're saying that the "exclude_idle"
modifier has never done anything useful and still doesn't?
If so I should update the perf_event_open manpage to spell this out.
Vince
: -22
Presumably this is due to the introduction of the perf_kprobe PMU in
commit e12f03d7031a977356e3d7b75a68c2185ff8d155
Author: Song Liu
Date: Wed Dec 6 14:45:15 2017 -0800
Is there a way to get this error disabled, or else rate-limited?
Vince
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:
ither the commit log is really misleading, or else a poor name was chosen
for this feature.
Vince
> Userspace RDPMC cannot possibly work for large PEBS, which was introduced in:
>
> b8241d20699e ("perf/x86/intel: Implement batched PEBS interrupt handling
> (large PEBS inte
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 "pti=
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
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
per
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.
Vince
rf_event_paranoid=2) so it might depend on how much of the PMU is
virtualized.
Vince
nel: [ 1078.931403] WARNING: stack recursion on stack
type 4
Jan 11 13:44:01 core2 kernel: [ 1078.931411] WARNING: can't dereference
registers at 2c6beb99 for ip
swapgs_restore_regs_and_return_to_usermode+0x2b/0x7c
Vince
On Thu, 11 Jan 2018, Vince Weaver wrote:
> on the same core2 machine I got this which didn't crash the machine (but
> the perf_fuzzer process is stuck)
also got this one:
Cannot open /sys/kernel/tracing/kprobe_events
[ 408.159243] watchdog: BUG: soft lockup - CPU#1 st
on the same core2 machine I got this which didn't crash the machine (but
the perf_fuzzer process is stuck)
[ 4592.608066] INFO: task systemd-logind:488 blocked for more than 120 seconds.
[ 4592.615159] Not tainted 4.15.0-rc7+ #211
[ 4592.619648] "echo 0 > /proc/sys/kernel/hung_task_timeout
On Thu, 11 Jan 2018, Vince Weaver wrote:
> On Thu, 11 Jan 2018, Peter Zijlstra wrote:
>
> > OK, I'm going to try fuzzing as a user with paranoid=0, and if that
> > doesn't help, I'm going to switch to linus' tree with my patches on.
>
> OK, I'
On Thu, 11 Jan 2018, Peter Zijlstra wrote:
> OK, I'm going to try fuzzing as a user with paranoid=0, and if that
> doesn't help, I'm going to switch to linus' tree with my patches on.
OK, I'm fuzzing on a core2 machine and it locks up too.
It did give the following first (but it kept going for a
be trying any of those patches?
Currently I can still lock my machines pretty quickly. I have been doing
some more tests. Machines don't crash if paranoid is "2" but will if
paranoid is "1".
Vince
On Tue, 9 Jan 2018, Vince Weaver wrote:
> Also I managed to hit (presumably) the same bug on a skylake machine.
> That one doesn't have a serial cable hooked up to it, I'll try to see if I
> can find one.
>
> I am running debian-unstable with gcc 7.2 if it makes a
hooked up to it, I'll try to see if I
can find one.
I am running debian-unstable with gcc 7.2 if it makes a difference.
Vince
tate that I can start fuzzing on them.
(extra challenge, the lab my machines is in possibly has a leak in the
roof, and they're calling for an inch of rain on top of 3 feet of
existing snow so I might have to shut everything down and relocate on
short notice).
Vince
n that would help? I tried KASAN
but it didn't help. I think I have the regular lockdep stuff enabled.
alt-sysrq doesn't work either (or at least, the version using BREAK over
the serial console doesn't, I can maybe try hooking up a keyboard/display
to see if that helps).
Vince
s a difference.
I can also try on a few other machines. I started setting up a fuzzing
cluster for this kind of thing but the multiport serial card I got for
logging the serial consoles crashes fairly quickly under load and I
haven't had time to track that down.
Vince
ew hours, no problems.
With KPTI enabled the perf_fuzzer on this haswell machine will lock up
within minutes.
It's a hard lockup with nothing over the serial console. It is not
deterministic/reproducible either.
Vince
Hello
Was trying out current git (4.15-rc7) and the perf_fuzzer very quickly
will lock up my Haswell test machine so solidly that I don't get any debug
info, even with a serial console.
I'll try enabling various debug options to see if I can get a more useful
bug report.
Vince
o perform a test of both
operands to avoid having unsigned wrap.
Signed-off-by: Vince Kim
---
Cahnges in v2:
- added missing opening curly brace at if statement
drivers/input/touchscreen/cyttsp4_core.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/input/touch
There are several places to perform subtraction to calculate buffer
size such as:
si->si_ofs.cydata_size = si->si_ofs.test_ofs - si->si_ofs.cydata_ofs;
...
p = krealloc(si->si_ptrs.cydata, si->si_ofs.cydata_size, GFP_KERNEL);
Actually, data types of above variables during subtraction are size_t,
On Tue, 19 Sep 2017, Eric W. Biederman wrote:
> When sorting out the si_code ambiguity fcntl I accidentally overshot and
> included SIGPOLL as well. Ooops! This is my trivial fix for that.
>
> Vince Weaver caught this when it landed in your tree with his
> perf_event_test
On Wed, 13 Sep 2017, Vince Weaver wrote:
> I just compiled up a fresh git kernel and all of the perf_event_test
> overflow tests are failing.
>
> The reason is that instead of getting POLL_IN or POLL_HUP sources as
> expected, they are getting weird results in si_code of "
otice that some major changes
to si_code handling went in with
64a76d0d64bea159da997c002a916ffc03f98bfc
Vince
; to operate that. I did run Vince's tests on it, and I think it doesn't
> regress, but I'm near a migraine so I can't really see straight atm.
>
> Vince, Stephane, could you guys have a peek?
I have to admit that I *always* got lost trying to figure out the old
so
2-g2627393 #2 SMP PREEMPT Fri Aug 11 13:58:42 EDT
2017 aarch64 GNU/Linux
$ ./mmap_multiple
Trying to mmap same perf_event fd multiple times...PASSED
So maybe the issue was fixed between 4.9 and current?
Vince
rns, that I had to special case in a few of my tests.
Vince
(0x7fc649e900, 0, -1, -1, 0) = 3
mmap(NULL, 36864, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7f7e1b1000
mmap(NULL, 36864, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = -1 EINVAL (Invalid
argument)
Vince
perf_event_open() file descriptor multiple times
and it works.
On ARM/ARM64 you can only mmap() it once, any other attempts fail.
Is this expected behavior?
You can run the
tests/record_sample/mmap_multiple
test in the current git of my perf_event_tests testsuite for a testcase.
Vince
;NEW BEHAVIOR' thing something I should worry about?
no, sorry, I've been working on cleaning up the outputs of the tests to be
less confusing.
NEW BEHAVIOR here means it has the "new" (since Linux 3.12) cap_usr_rdpmc
bit layout.
Vince
to fix things.
With both this and the other patch applied PAPI can finally pass all of
its validation tests when running with RDPMC support enabled.
Thanks,
Vince
1 - 100 of 920 matches
Mail list logo
