summaryrefslogtreecommitdiff
path: root/include/net/aligned_data.h
diff options
context:
space:
mode:
authorLuo Gengkun <luogengkun@huaweicloud.com>2025-06-04 03:39:24 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-06-27 11:11:45 +0100
commitfd199366bf3862402116b2e270d5c9e7adbc5c0a (patch)
treed3450bc7451e781d4dee2cb38a30c5d90f0f2a6c /include/net/aligned_data.h
parent7335c33d621fd8f942fdf9f4ef1e9dbd01712b1a (diff)
perf/core: Fix WARN in perf_cgroup_switch()
[ Upstream commit 3172fb986666dfb71bf483b6d3539e1e587fa197 ] There may be concurrency between perf_cgroup_switch and perf_cgroup_event_disable. Consider the following scenario: after a new perf cgroup event is created on CPU0, the new event may not trigger a reprogramming, causing ctx->is_active to be 0. In this case, when CPU1 disables this perf event, it executes __perf_remove_from_context-> list _del_event->perf_cgroup_event_disable on CPU1, which causes a race with perf_cgroup_switch running on CPU0. The following describes the details of this concurrency scenario: CPU0 CPU1 perf_cgroup_switch: ... # cpuctx->cgrp is not NULL here if (READ_ONCE(cpuctx->cgrp) == NULL) return; perf_remove_from_context: ... raw_spin_lock_irq(&ctx->lock); ... # ctx->is_active == 0 because reprogramm is not # tigger, so CPU1 can do __perf_remove_from_context # for CPU0 __perf_remove_from_context: perf_cgroup_event_disable: ... if (--ctx->nr_cgroups) ... # this warning will happened because CPU1 changed # ctx.nr_cgroups to 0. WARN_ON_ONCE(cpuctx->ctx.nr_cgroups == 0); [peterz: use guard instead of goto unlock] Fixes: db4a835601b7 ("perf/core: Set cgroup in CPU contexts for new cgroup events") Signed-off-by: Luo Gengkun <luogengkun@huaweicloud.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20250604033924.3914647-3-luogengkun@huaweicloud.com Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'include/net/aligned_data.h')
0 files changed, 0 insertions, 0 deletions