mmio_pipe_open() allocates a header_iter and takes a pci_dev reference
when trace_pipe is opened. mmio_close() frees them, but it was only
wired to the tracer's .close callback.

tracing_release_pipe() invokes .pipe_close, not .close, when the
trace_pipe file is released. As a result, closing trace_pipe with the
mmiotrace tracer active leaked the header_iter allocation and left a
stale pci_dev reference.

Set .pipe_close to mmio_close, matching how function_graph wires both
callbacks to the same handler.

Signed-off-by: deepakraog <gaikwad.dcg@gmail.com>
---
 kernel/trace/trace_mmiotrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index 226cf66e0..20812e7f9 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
@@ -109,7 +109,6 @@ static void mmio_pipe_open(struct trace_iterator *iter)
 	iter->private = hiter;
 }
 
-/* XXX: This is not called when the pipe is closed! */
 static void mmio_close(struct trace_iterator *iter)
 {
 	struct header_iter *hiter = iter->private;
@@ -279,6 +278,7 @@ static struct tracer mmio_tracer __read_mostly =
 	.start		= mmio_trace_start,
 	.pipe_open	= mmio_pipe_open,
 	.close		= mmio_close,
+	.pipe_close	= mmio_close,
 	.read		= mmio_read,
 	.print_line	= mmio_print_line,
 	.noboot		= true,
-- 
Deepak Rao Gaikwad

On Wed, 15 Jul 2026 20:06:04 +0530
deepakraog <gaikwad.dcg@gmail.com> wrote:

> mmio_pipe_open() allocates a header_iter and takes a pci_dev reference
> when trace_pipe is opened. mmio_close() frees them, but it was only
> wired to the tracer's .close callback.

Were you able to trigger a kmemleak?

> 
> tracing_release_pipe() invokes .pipe_close, not .close, when the
> trace_pipe file is released. As a result, closing trace_pipe with the
> mmiotrace tracer active leaked the header_iter allocation and left a
> stale pci_dev reference.

It would be good if you showed how a leak can happen, as the mmio_read()
does clean up the descriptor, making the above statement incorrect.

> 
> Set .pipe_close to mmio_close, matching how function_graph wires both
> callbacks to the same handler.
> 


The mmio_read() will free up the descriptor if you read the trace_pipe file
until it blocks. But reading part of it may trigger the leak. Such as:

  # head -n 1 /sys/kernel/tracing/trace_pipe 
 head: /sys/kernel/tracing/trace_pipe: cannot seek to relative offset 0: Illegal seek
 VERSION 20070824

and running that over and over again will produce a leak caught by kmemleak.

I'll update the change log.

-- Steve