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
