From: Ravi Bangoria <ravi.bangoria@amd.com>
To: George Kennedy <george.kennedy@oracle.com>
Cc: harshit.m.mogalapalli@oracle.com, peterz@infradead.org,
mingo@redhat.com, acme@kernel.org, namhyung@kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com,
kan.liang@linux.intel.com, tglx@linutronix.de, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Ravi Bangoria <ravi.bangoria@amd.com>
Subject: Re: [PATCH] perf/x86/amd: check event before enable to avoid GPF
Date: Mon, 10 Jun 2024 16:21:38 +0530 [thread overview]
Message-ID: <78db946d-db24-408e-92fc-b7ff79c80728@amd.com> (raw)
In-Reply-To: <36e86320-1a43-45d4-b25e-a5d60857f4b2@oracle.com>
On 6/8/2024 12:43 AM, George Kennedy wrote:
> Hi Ravi,
>
> On 6/4/2024 9:40 AM, Ravi Bangoria wrote:
>>> On 6/4/2024 9:16 AM, Ravi Bangoria wrote:
>>>>>>>> Events can be deleted and the entry can be NULL.
>>>>>>> Can you please also explain "how".
>>>>>> It looks like x86_pmu_stop() is clearing the bit in active_mask and setting the events entry to NULL (and doing it in the correct order) for the same events index that amd_pmu_enable_all() is trying to enable.
>>>>>>>> Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.
>>>>>>>> This appears to be an AMD only issue.
>>>>>>>>
>>>>>>>> Syzkaller reported a GPF in amd_pmu_enable_all.
>>>>>>> Can you please provide a bug report link? Also, any reproducer?
>>>>>> The Syzkaller reproducer can be found in this link:
>>>>>> https://lore.kernel.org/netdev/CAMt6jhyec7-TSFpr3F+_ikjpu39WV3jnCBBGwpzpBrPx55w20g@mail.gmail.com/T/#u
>>>>>>>> @@ -760,7 +760,8 @@ static void amd_pmu_enable_all(int added)
>>>>>>>> if (!test_bit(idx, cpuc->active_mask))
>>>>>>>> continue;
>>>>>>>> - amd_pmu_enable_event(cpuc->events[idx]);
>>>>>>>> + if (cpuc->events[idx])
>>>>>>>> + amd_pmu_enable_event(cpuc->events[idx]);
>>>>>>> What if cpuc->events[idx] becomes NULL after if (cpuc->events[idx]) but
>>>>>>> before amd_pmu_enable_event(cpuc->events[idx])?
>>>>>> Good question, but the crash has not reproduced with the proposed fix in hours of testing. It usually reproduces within minutes without the fix.
>>>>> Also, a similar fix is done in __intel_pmu_enable_all() in arch/x86/events/intel/core.c except that a WARN_ON_ONCE is done as well.
>>>>> See: https://elixir.bootlin.com/linux/v6.10-rc1/source/arch/x86/events/intel/core.c#L2256
>>>> There are subtle differences between Intel and AMD pmu implementation.
>>>> __intel_pmu_enable_all() enables all event with single WRMSR whereas
>>>> amd_pmu_enable_all() loops over each PMC and enables it individually.
>>>>
>>>> The WARN_ON_ONCE() is important because it will warn about potential
>>>> sw bug somewhere else.
>>> We could add a similar WARN_ON_ONCE() to the proposed patch.
>> Sure, that would help in future. But for current splat, can you please
>> try to rootcause the underlying race condition?
>
> Were you able to reproduce the crash on the AMD machine?
I'm able to reproduce within the KVM guest. Will try to investigate further.
Thanks,
Ravi
next prev parent reply other threads:[~2024-06-10 10:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-29 13:50 [PATCH] perf/x86/amd: check event before enable to avoid GPF George Kennedy
2024-05-30 3:37 ` Ravi Bangoria
2024-05-30 18:30 ` George Kennedy
2024-05-30 20:26 ` George Kennedy
2024-06-04 13:16 ` Ravi Bangoria
2024-06-04 13:23 ` George Kennedy
2024-06-04 13:40 ` Ravi Bangoria
2024-06-04 14:26 ` George Kennedy
2024-06-07 19:13 ` George Kennedy
2024-06-10 10:51 ` Ravi Bangoria [this message]
2024-06-24 16:18 ` George Kennedy
2024-07-01 14:15 ` George Kennedy
2024-07-02 4:03 ` Ravi Bangoria
2024-07-02 11:38 ` George Kennedy
2024-09-24 17:13 ` George Kennedy
2024-09-26 4:05 ` Ravi Bangoria
2024-06-03 4:39 ` Ravi Bangoria
2024-06-03 13:30 ` George Kennedy
2024-06-04 13:02 ` Ravi Bangoria
2024-06-04 13:00 ` Ravi Bangoria
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=78db946d-db24-408e-92fc-b7ff79c80728@amd.com \
--to=ravi.bangoria@amd.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=george.kennedy@oracle.com \
--cc=harshit.m.mogalapalli@oracle.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).