From: Steven Rostedt <rostedt@goodmis.org>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCH] tracing: Do not clean up hiter in mmiotrace read function
Date: Thu, 23 Jul 2026 09:49:58 -0400 [thread overview]
Message-ID: <20260723094958.47c2dfea@gandalf.local.home> (raw)
In-Reply-To: <20260723082435.3dcdef7b52fe661d6ff506c9@kernel.org>
On Thu, 23 Jul 2026 08:24:35 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> On Tue, 21 Jul 2026 21:20:10 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > From: Steven Rostedt <rostedt@goodmis.org>
> >
> > When the mmiotrace trace was first created, it allocated a descriptor in
> > its pipe_open() method. Since there was no pipe_close() method when it was
> > created (in May of 2008, and pipe_close() was added in December of 2009),
> > it cleaned up the allocated descriptors in the read.
> >
> > Now that the clean up is in the pipe_close() method that now exists,
> > remove the clean up from the read as it is no longer needed.
> >
> > Also simplify the code by inverting the early exit conditional into a
> > conditional to perform the logic and get rid of the goto.
> >
> > Link: https://lore.kernel.org/all/20260715143604.14481-1-gaikwad.dcg@gmail.com/
> > Link: https://lore.kernel.org/all/20260721211143.36dbd559@gandalf.local.home/
> >
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > ---
> > kernel/trace/trace_mmiotrace.c | 14 +++-----------
> > 1 file changed, 3 insertions(+), 11 deletions(-)
> >
> > diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
> > index b88b8d9923ad..ba604c22d2d2 100644
> > --- a/kernel/trace/trace_mmiotrace.c
> > +++ b/kernel/trace/trace_mmiotrace.c
> > @@ -142,21 +142,13 @@ static ssize_t mmio_read(struct trace_iterator *iter, struct file *filp,
> > if (!overrun_detected)
> > pr_warn("mmiotrace has lost events\n");
> > overrun_detected = true;
> > - goto print_out;
>
> Is this intentional change? Removing this goto means we will change
> the hiter->dev even if overrun happens. Previously we can resume
> output in the next read for current hiter->dev, but this will skip
> the current hiter->dev?
But doesn't it still add to the buffer here?
>
> Thanks,
>
> > }
> >
> > - if (!hiter || !hiter->dev)
> > - return 0;
> > -
> > - mmio_print_pcidev(s, hiter->dev);
> > - hiter->dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, hiter->dev);
> > -
> > - if (!hiter->dev) {
> > - destroy_header_iter(hiter);
> > - iter->private = NULL;
> > + if (hiter && hiter->dev) {
> > + mmio_print_pcidev(s, hiter->dev);
The current hiter->dev get's read here doesn't it?
It's stored in the trace_seq and should still be printed.
Or am I missing something?
Either way, it looks like I should split this patch up into two:
One that removes the unneeded clean up, and the other that removes the
goto. The clean up removal is trivial with the new changes that cleans it
up on close. But the removal of the goto has more subtle effects and we
want to be able to detect it if it does cause issues.
I wasn't planning on adding this patch to the next merge window anyway, so
it can wait.
-- Steve
> > + hiter->dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, hiter->dev);
> > }
> >
> > -print_out:
> > ret = trace_seq_to_user(s, ubuf, cnt);
> > return (ret == -EBUSY) ? 0 : ret;
> > }
> > --
> > 2.53.0
> >
>
>
next prev parent reply other threads:[~2026-07-23 13:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 1:20 [PATCH] tracing: Do not clean up hiter in mmiotrace read function Steven Rostedt
2026-07-22 23:24 ` Masami Hiramatsu
2026-07-23 13:49 ` Steven Rostedt [this message]
2026-07-23 23:10 ` Masami Hiramatsu
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=20260723094958.47c2dfea@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.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