From: Frederic Weisbecker <frederic@kernel.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [bug report] perf: Fix event leak upon exec and file release
Date: Wed, 2 Oct 2024 15:51:41 +0200 [thread overview]
Message-ID: <Zv1P7UzPWvFjOupc@localhost.localdomain> (raw)
In-Reply-To: <20240930090439.3IgzQVzB@linutronix.de>
Le Mon, Sep 30, 2024 at 11:04:39AM +0200, Sebastian Andrzej Siewior a écrit :
> On 2024-09-02 23:47:08 [+0200], Frederic Weisbecker wrote:
> > Ah right.
> >
> > So one possible fix is to possibly let the task work do the last reference
> > decrement. This would mean that freeing children events can't be always assumed
> > by the parent.
> >
> > The below (only built tested) would do it?
>
> This looks nice based on diffstat. I didn't look closed nor did any
> testing so far. Do we like it and wait for Dan here or?
No eventually I think the issues reported by Dan can't happen because:
pl330_free_chan_resources() <- disables preempt
-> pl330_release_channel()
-> _free_event()
-> perf_pending_task_sync()
That's another _free_event that is not related to perf.
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()
The put_event() calls here and above can't be the last ones. Because
if an event is attached to an aux event, detaching from it means that
aux event itself hasn't even gone through perf_event_remove_from_context().
Similarly an exiting aux event detaching the events from it means those attached
events haven't gone through perf_event_remove_from_context().
So this should be fine (famous last words). There is a might_sleep() call in
irq_work_sync() that should tell us about it.
Thanks.
next prev parent reply other threads:[~2024-10-02 13:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 13:43 [bug report] perf: Fix event leak upon exec and file release Dan Carpenter
2024-09-02 21:47 ` Frederic Weisbecker
2024-09-30 9:04 ` Sebastian Andrzej Siewior
2024-10-02 13:51 ` Frederic Weisbecker [this message]
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=Zv1P7UzPWvFjOupc@localhost.localdomain \
--to=frederic@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=dan.carpenter@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=peterz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).