From: Ravi Bangoria <ravi.bangoria@amd.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@kernel.org, lucas.demarchi@intel.com,
linux-kernel@vger.kernel.org, willy@infradead.org,
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, Ravi Bangoria <ravi.bangoria@amd.com>
Subject: Re: [PATCH v2 24/24] perf: Make perf_pmu_unregister() useable
Date: Mon, 10 Feb 2025 12:12:40 +0530 [thread overview]
Message-ID: <1f4e4bb1-ba5e-4e5f-b6e3-e7603e3d6b0e@amd.com> (raw)
In-Reply-To: <20250205102450.888979808@infradead.org>
> @@ -13467,7 +13665,13 @@ perf_event_exit_event(struct perf_event
> * Kick perf_poll() for is_event_hup();
> */
> perf_event_wakeup(parent_event);
> - free_event(event);
> + /*
> + * pmu_detach_event() will have an extra refcount.
> + */
> + if (revoke)
> + put_event(event);
> + else
> + free_event(event);
> put_event(parent_event);
> return;
> }
There is a race between do_exit() and perf_pmu_unregister():
Assume: a Parent process with 'event1' and a Child process with an
inherited 'event2'.
CPU 1 CPU 2
Child process exiting ...
1 do_exit()
2 perf_event_exit_task()
3 perf_event_exit_task_context()
4 mutex_lock(&child_ctx->mutex);
5 list_for_each_entry_safe(&child_ctx->event_list)
6 /* picks event2. event2->refcount is 1 */
7 perf_pmu_unregister()
8 pmu_detach_events()
9 pmu_get_event(pmu) /* Picks event2 */
10 atomic_long_inc_not_zero(&event->refcount) /* event2 */
11 /* event2->refcount becomes 2 */
12 pmu_detach_event() /* event2 */
13 perf_event_ctx_lock(); /* event2 */
14 /* event2->refcount became 2 (by CPU 2) */ .
15 perf_event_exit_event() /* event2 */ . /* CPU 1 is holding ctx->mutex of
16 if (parent_event) { /* true */ . child process. Waiting ... */
17 if (revoke) /* false */ .
18 else .
19 free_event(); /* event2 */ .
20 WARN() .
^^^^^^
This race manifests as:
unexpected event refcount: 2; ptr=00000000c6ca2049
WARNING: CPU: 57 PID: 9729 at kernel/events/core.c:5439 free_event+0x48/0x60
RIP: 0010:free_event+0x48/0x60
Call Trace:
? free_event+0x48/0x60
perf_event_exit_event.isra.0+0x60/0xf0
perf_event_exit_task+0x1e1/0x280
do_exit+0x327/0xb00
The race continues... now, with the stale child2->parent pointer:
CPU 1 CPU 2
15 perf_event_exit_event() /* event2 */ . /* CPU 1 is holding ctx->mutex of
16 if (parent_event) { /* true */ . child process. Waiting ... */
17 if (revoke) /* false */ .
18 else .
19 free_event(); /* event2 */ .
20 WARN() .
21 put_event(parent_event); /* event1 */ .
22 /* event1->refcount becomes 1 */ .
23 } .
24 +- mutex_unlock(&child_ctx->mutex); . /* Acquired child's ctx->mutex */
25 __pmu_detach_event() /* event2 */
26 perf_event_exit_event() /* event2 */
27 if (parent_event) { /* true, BUT FALSE POSITIVE. */
28 if (revoke) /* true */
29 put_event(); /* event2 */
30 /* event2->refcount becomes 1 */
31 put_event(parent_event); /* event1 */
32 /* event1->refcount becomes 0 */
^^^^^^^^^^^^^^^^^^^^^^^^^^
This can manifest as some random bug. I guess, perf_event_exit_event()
should also check for (event->attach_state & PERF_ATTACH_CHILD) when
event->parent != NULL.
Thanks,
Ravi
next prev parent reply other threads:[~2025-02-10 6:42 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 10:21 [PATCH v2 00/24] perf: Make perf_pmu_unregister() usable Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 01/24] lockdep: Fix might_fault() Peter Zijlstra
2025-02-06 18:19 ` David Hildenbrand
2025-02-05 10:21 ` [PATCH v2 02/24] perf: Ensure bpf_perf_link path is properly serialized Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 03/24] perf: Simplify child event tear-down Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 04/24] perf: Simplify perf_event_free_task() wait Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 05/24] perf: Simplify perf_event_release_kernel() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 06/24] perf: Fix pmus_lock vs pmus_srcu ordering Peter Zijlstra
2025-02-27 16:59 ` Lucas De Marchi
2025-02-05 10:21 ` [PATCH v2 07/24] perf: Fix perf_pmu_register() vs perf_init_event() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 08/24] perf: Cleanup perf_try_init_event() Peter Zijlstra
2025-03-05 11:29 ` [tip: perf/core] perf/core: Clean up perf_try_init_event() tip-bot2 for Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 09/24] perf: Simplify perf_event_alloc() error path Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 10/24] perf: Simplify perf_pmu_register() " Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 11/24] perf: Simplify perf_pmu_register() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 12/24] perf: Simplify perf_init_event() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 13/24] perf: Simplify perf_event_alloc() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 14/24] perf: Merge pmu_disable_count into cpu_pmu_context Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 15/24] perf: Add this_cpc() helper Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 16/24] perf: Detach perf_cpu_pmu_context and pmu lifetimes Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 17/24] perf: Introduce perf_free_addr_filters() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 18/24] perf: Robustify perf_event_free_bpf_prog() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 19/24] perf: Simplify perf_mmap() control flow Peter Zijlstra
2025-03-03 5:39 ` Ravi Bangoria
2025-03-03 11:19 ` Ingo Molnar
2025-03-03 13:36 ` Ravi Bangoria
2025-03-04 8:44 ` Ingo Molnar
2025-02-05 10:21 ` [PATCH v2 20/24] perf: Fix perf_mmap() failure path Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 21/24] perf: Further simplify perf_mmap() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 22/24] perf: Remove retry loop from perf_mmap() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 23/24] perf: Lift event->mmap_mutex in perf_mmap() Peter Zijlstra
2025-02-05 10:21 ` [PATCH v2 24/24] perf: Make perf_pmu_unregister() useable Peter Zijlstra
2025-02-10 6:39 ` Ravi Bangoria
2025-02-11 15:46 ` Peter Zijlstra
2025-02-10 6:42 ` Ravi Bangoria [this message]
2025-02-12 12:49 ` Peter Zijlstra
2025-02-13 7:52 ` Ravi Bangoria
2025-02-13 13:08 ` Peter Zijlstra
2025-02-14 3:57 ` Ravi Bangoria
2025-02-14 20:24 ` Peter Zijlstra
2025-02-17 8:24 ` Ravi Bangoria
2025-02-17 16:31 ` Ravi Bangoria
2025-02-19 13:23 ` Ravi Bangoria
2025-02-19 14:30 ` Ravi Bangoria
2025-02-10 6:59 ` Ravi Bangoria
2025-02-13 13:07 ` Peter Zijlstra
2025-03-03 6:01 ` [PATCH v2 00/24] perf: Make perf_pmu_unregister() usable 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=1f4e4bb1-ba5e-4e5f-b6e3-e7603e3d6b0e@amd.com \
--to=ravi.bangoria@amd.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.