From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>,
Aditya Chillara <quic_achillar@quicinc.com>
Cc: Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] tracing: Prevent double unregister of tracepoint probes
Date: Wed, 9 Jul 2025 10:51:12 -0400 [thread overview]
Message-ID: <7f5ce50e-d1fa-4180-95ae-201195521e12@efficios.com> (raw)
In-Reply-To: <20250709104017.69190334@batman.local.home>
On 2025-07-09 10:40, Steven Rostedt wrote:
> [ Added Mathieu who is the author of the tracepoint code ]
>
> On Wed, 9 Jul 2025 11:11:10 +0530
> Aditya Chillara <quic_achillar@quicinc.com> wrote:
>
>> Prevent tracepoint_probe_unregister from being executed multiple times
>> for the same probe, which can cause issues with perf due to the lack
>> of error handling.
>>
>> Return an error if the probe is not present in the list of probes.
>
> This patch even shows that the first patch is fixing a symptom.
>
> Yes, I agree with this patch (with some cleanups below), but there
> should be no reason for perf to be ever calling unreg() if it doesn't
> have a tracepoint registered. Something else got screwed up in the mean
> time.
>
Agreed.
>>
>> Signed-off-by: Aditya Chillara <quic_achillar@quicinc.com>
>> ---
>> kernel/tracepoint.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
>> index ef42c1a1192053cc05b45ccb61358a4996453add..e6eee7e44a9d6f4f19114fbcf8fd9e5c85075324 100644
>> --- a/kernel/tracepoint.c
>> +++ b/kernel/tracepoint.c
>> @@ -232,7 +232,7 @@ func_add(struct tracepoint_func **funcs, struct tracepoint_func *tp_func,
>> static void *func_remove(struct tracepoint_func **funcs,
>> struct tracepoint_func *tp_func)
>> {
>> - int nr_probes = 0, nr_del = 0, i;
>> + int nr_probes = 0, nr_del = 0, nr_tp_stub_del = 0, i;
>> struct tracepoint_func *old, *new;
>>
>> old = *funcs;
>> @@ -246,11 +246,18 @@ static void *func_remove(struct tracepoint_func **funcs,
>> for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
>> if ((old[nr_probes].func == tp_func->func &&
>> old[nr_probes].data == tp_func->data) ||
>> - old[nr_probes].func == tp_stub_func)
>> + old[nr_probes].func == tp_stub_func) {
>> + if (old[nr_probes].func == tp_stub_func)
>> + nr_tp_stub_del++;
>> nr_del++;
>> + }
>
> I would make this a bit cleaner by:
>
> if ((old[nr_probes].func == tp_func->func &&
> old[nr_probes].data == tp_func->data))
> nr_del++;
>
> if (old[nr_probes].func == tp_stub_func)
> nr_tp_stub_del++;
>> }
>> }
>>
>> + /* If there is nothing to delete, do not allow */
>> + if (nr_del - nr_tp_stub_del == 0)
>> + return ERR_PTR(-ENOENT);
>
> if (!nr_del)
> return ERR_PTR(-ENOENT);
>
> nr_del += nr_tp_stub_del;
>
Indeed func_remove() already returns ERR_PTR(-ENOENT) when
old is NULL at the beginning of the function, so its intent
is indeed to catch this kind of scenario. I agree with Steven's
recommended changes.
Thanks,
Mathieu
> -- Steve
>
>> +
>> /*
>> * If probe is NULL, then nr_probes = nr_del = 0, and then the
>> * entire entry will be removed.
>>
>
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
prev parent reply other threads:[~2025-07-09 14:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-09 5:41 [PATCH 0/2] tracing/perf: Prevent double unregister of perf and tracepoint probes Aditya Chillara
2025-07-09 5:41 ` [PATCH 1/2] tracing/perf: Prevent double unregister of perf probes Aditya Chillara
2025-07-09 14:23 ` Steven Rostedt
2025-07-09 16:50 ` Aditya Chillara
2025-07-09 17:18 ` Steven Rostedt
2025-07-11 18:40 ` Aditya Chillara
2025-07-18 7:35 ` Aditya Chillara
2025-07-09 5:41 ` [PATCH 2/2] tracing: Prevent double unregister of tracepoint probes Aditya Chillara
2025-07-09 14:40 ` Steven Rostedt
2025-07-09 14:51 ` Steven Rostedt
2025-07-09 14:51 ` Mathieu Desnoyers [this message]
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=7f5ce50e-d1fa-4180-95ae-201195521e12@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=quic_achillar@quicinc.com \
--cc=rostedt@goodmis.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