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 <[email protected]> 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/[email protected]?part=1
