Re: [PATCH] tracing/mmiotrace: fix resource leak on trace_pipe close
Steven Rostedt <[email protected]> Tue, 21 Jul 2026 20:38:43 -0400
| Newsgroups | org.freedesktop.lists.nouveau,org.kernel.vger.linux-kernel,org.kernel.vger.linux-trace-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 15 Jul 2026 20:06:04 +0530 deepakraog <[email protected]> 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