Re: [PATCH v6 1/2] perf: Fix null pointer access in is_include_guest_event()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message claims that `READ_ONCE` was added to `is_include_guest_event()` for checking the `pmu` state, but the code lacks this instruction.
--

commit 7c0504a46d493eec58eae8ca000ce324320508fd
Author: Vinay Belgaumkar <vinay.belgaumkar@intel.com>

perf: Fix null pointer access in is_include_guest_event()

This commit addresses a null pointer dereference in is_include_guest_event()
caused by a module unload occurring while a perf connection is active. It adds
a null check for the pmu pointer and calls mediated_pmu_unaccount_event()
before clearing the pointer to maintain the event counts correctly.

> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index a6c8e38a31104..7777e82aad5e7 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -6350,6 +6350,9 @@ static DEFINE_MUTEX(perf_mediated_pmu_mutex);
>  /* !exclude_guest event of PMU with PERF_PMU_CAP_MEDIATED_VPMU */
>  static inline bool is_include_guest_event(struct perf_event *event)
>  {
> +	if (!event->pmu)
> +		return false;
> +
>  	if ((event->pmu->capabilities & PERF_PMU_CAP_MEDIATED_VPMU) &&

[Severity: Medium]
The commit message claims that READ_ONCE was added for checking the pmu state,
but the code lacks this instruction here.

Without READ_ONCE(), the compiler is free to issue two independent memory loads
of event->pmu: one for the null check and one for accessing capabilities.

Could this leave a potential double-read hazard if event->pmu is concurrently
nullified by __pmu_detach_event() while is_include_guest_event() is executing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902141824.733112-1-vinay.belgaumkar@intel.com?part=1