Re: [PATCH v1] tracing/remotes: Fix leak in trace_remote_alloc_buffer() error path
From: Vincent Donnefort <hidden>
Date: 2026-07-09 12:18:43
Also in:
lkml
On Wed, Jul 08, 2026 at 12:59:06PM -0400, Steven Rostedt wrote:
On Wed, 8 Jul 2026 14:32:01 +0100 Vincent Donnefort [off-list ref] wrote:quoted
If page allocation fails in trace_remote_alloc_buffer(), desc->nr_cpus is not yet incremented for the current CPU. As a consequence, on error, half-allocated rb_desc will not be freed in trace_remote_free_buffer(). Include the failing CPU in desc->nr_cpus before going to the error path.Looks like Sashiko found other issues you may want to address: https://sashiko.dev/#/patchset/20260708133201.295072-1-vdonnefort%40google.com
Yeah I saw it, the dreaded "This isn't a bug introduced by this patch" ... Let me send a follow-up. After looking at the other issue, I think I want to slightly modify this one actually!
-- Stevequoted
Fixes: 96e43537af54 ("tracing: Introduce trace remotes") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Vincent Donnefort <redacted>diff --git a/kernel/trace/trace_remote.c b/kernel/trace/trace_remote.c index 2a6cc000ec98..62d3d431c309 100644 --- a/kernel/trace/trace_remote.c +++ b/kernel/trace/trace_remote.c@@ -1008,8 +1008,10 @@ int trace_remote_alloc_buffer(struct trace_buffer_desc *desc, size_t desc_size, for (id = 0; id < nr_pages; id++) { rb_desc->page_va[id] = (unsigned long)__get_free_page(GFP_KERNEL); - if (!rb_desc->page_va[id]) + if (!rb_desc->page_va[id]) { + desc->nr_cpus++; /* Free this partially-allocated rb_desc */ goto err; + } rb_desc->nr_page_va++; }base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda