From: Dan Carpenter <dan.carpenter@linaro.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: linux-perf-users@vger.kernel.org
Subject: [bug report] perf: Fix event leak upon exec and file release
Date: Fri, 23 Aug 2024 16:43:33 +0300 [thread overview]
Message-ID: <5cc313bc-c44d-4f6c-80ee-5a9fe9356f43@stanley.mountain> (raw)
Hello Frederic Weisbecker,
Commit 3a5465418f5f ("perf: Fix event leak upon exec and file
release") from Jun 21, 2024 (linux-next), leads to the following
Smatch static checker warning:
kernel/events/core.c:5301 perf_pending_task_sync()
warn: sleeping in atomic context
kernel/events/core.c
5280 static void perf_pending_task_sync(struct perf_event *event)
5281 {
5282 struct callback_head *head = &event->pending_task;
5283
5284 if (!event->pending_work)
5285 return;
5286 /*
5287 * If the task is queued to the current task's queue, we
5288 * obviously can't wait for it to complete. Simply cancel it.
5289 */
5290 if (task_work_cancel(current, head)) {
5291 event->pending_work = 0;
5292 local_dec(&event->ctx->nr_no_switch_fast);
5293 return;
5294 }
5295
5296 /*
5297 * All accesses related to the event are within the same RCU section in
5298 * perf_pending_task(). The RCU grace period before the event is freed
5299 * will make sure all those accesses are complete by then.
5300 */
--> 5301 rcuwait_wait_event(&event->pending_work_wait, !event->pending_work, TASK_UNINTERRUPTIBLE);
^^^^^^^^^^
The commit adds a sleep
5302 }
Smatch is complaining about four call trees which are holding a spinlock.
One:
pl330_free_chan_resources() <- disables preempt
-> pl330_release_channel()
-> _free_event()
-> perf_pending_task_sync()
Two and three:
perf_remove_from_context() <- disables preempt
__perf_event_exit_context() <- disables preempt
-> __perf_remove_from_context()
-> perf_group_detach()
-> perf_put_aux_event()
-> put_event()
-> _free_event()
-> perf_pending_task_sync()
Four:
perf_free_event() <- disables preempt
-> perf_group_detach()
-> perf_put_aux_event()
-> put_event()
-> _free_event()
-> perf_pending_task_sync()
This check tends to have more false positive when the call tree is long. For
example, maybe event->pending_work is always zero or something. I've looked it
over, but I'm a newbie to this code.
regards,
dan carpenter
next reply other threads:[~2024-08-23 13:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 13:43 Dan Carpenter [this message]
2024-09-02 21:47 ` [bug report] perf: Fix event leak upon exec and file release Frederic Weisbecker
2024-09-30 9:04 ` Sebastian Andrzej Siewior
2024-10-02 13:51 ` Frederic Weisbecker
2024-10-02 14:57 ` Dan Carpenter
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=5cc313bc-c44d-4f6c-80ee-5a9fe9356f43@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=frederic@kernel.org \
--cc=linux-perf-users@vger.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