From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
Vince Weaver <vincent.weaver@maine.edu>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
Stephane Eranian <eranian@google.com>
Subject: Re: [perf] perf_fuzzer causes crash in intel_pmu_drain_pebs_nhm()
Date: Mon, 1 Mar 2021 08:20:48 -0500 [thread overview]
Message-ID: <32888c33-c286-c600-66cb-8b1b03beeb8b@linux.intel.com> (raw)
In-Reply-To: <YCVE8q4MlbcU4fnV@hirez.programming.kicks-ass.net>
On 2/11/2021 9:53 AM, Peter Zijlstra wrote:
>
> Kan, do you have time to look at this?
>
> On Thu, Jan 28, 2021 at 02:49:47PM -0500, Vince Weaver wrote:
>> 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 to be caused in
>>
>> __intel_pmu_pebs_event()
>> get_next_pebs_record_by_bit() ds.c line 1639
>> get_pebs_status(at) ds.c line 1317
>> return ((struct pebs_record_nhm *)n)->status;
>>
>> where "n" has the value of 0xc0 rather than a proper pointer.
>>
I think I find the suspicious patch.
The commt id 01330d7288e00 ("perf/x86: Allow zero PEBS status with only
single active event")
https://lore.kernel.org/lkml/tip-01330d7288e0050c5aaabc558059ff91589e67cd@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 tries to minimize the impact of the
defect by avoiding dropping the PEBS records which have PEBS status 0.
But, it doesn't correct the PEBS status, which may bring problems,
especially for the large PEBS.
It's possible that all the PEBS records in a large PEBS have the PEBS
status 0. If so, the first get_next_pebs_record_by_bit() in the
__intel_pmu_pebs_event() returns NULL. The at = NULL. Since it's a large
PEBS, the 'count' parameter must > 1. The second
get_next_pebs_record_by_bit() will crash.
Could you please revert the patch and check whether it fixes your issue?
Thanks,
Kan
next prev parent reply other threads:[~2021-03-01 13:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 14:25 [perf] perf_fuzzer causes crash in intel_pmu_drain_pebs_nhm() Vince Weaver
2021-01-28 19:49 ` Vince Weaver
2021-02-11 14:53 ` Peter Zijlstra
2021-02-11 21:37 ` Liang, Kan
2021-02-11 22:14 ` Vince Weaver
2021-02-25 20:15 ` Liang, Kan
2021-03-01 13:20 ` Liang, Kan [this message]
2021-03-02 5:29 ` Vince Weaver
2021-03-03 18:16 ` [perf] perf_fuzzer causes unchecked MSR access error Vince Weaver
2021-03-03 19:28 ` Stephane Eranian
2021-03-03 20:00 ` Liang, Kan
2021-03-03 20:22 ` Vince Weaver
2021-03-04 19:33 ` Liang, Kan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32888c33-c286-c600-66cb-8b1b03beeb8b@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=vincent.weaver@maine.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox