From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Beau Belgrave <beaub@linux.microsoft.com>,
Andrew Morton <akpm@linux-foundation.org>,
sunliming <sunliming@kylinos.cn>
Subject: Re: [GIT PULL] tracing: user_event fix for 6.4
Date: Mon, 26 Jun 2023 02:07:31 -0400 [thread overview]
Message-ID: <20230626020731.299d0b10@rorschach.local.home> (raw)
In-Reply-To: <CAHk-=wirKv866nP=v3uBf0TTvaPxfSvAQUJfL2KB-NZboBVUaQ@mail.gmail.com>
On Sun, 25 Jun 2023 16:04:32 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The fact that your explanation is "we have that bug in other places"
> does *not* make me any happier.
Actually it's just the behavior inside the kernel. I just wrote a quick
program to see the behavior of /sys/kernel/tracing/trace_marker, and
yeah, it actually returns an error when writing if the ring buffer is
disabled.
I was trying to imitate the internal behavior in the kernel, but I
shouldn't have, as we control all the instances of that.
Now testing the other user space interface, it does behave the way you
described (something I implemented years ago!). So I will drop this
version of the patch.
From the code for trace_marker:
if (unlikely(!event))
/* Ring buffer disabled, return as if not open for write */
return -EBADF;
sunliming's original patch had it return an error. I'll have him redo
that one, because the current behavior is still wrong as it returns as
if it wrote something when it did not.
https://lore.kernel.org/all/20230608011554.1181097-2-sunliming@kylinos.cn/
We were the ones to tell him not to return an error, so I take the
blame on that. But if we are going to return an error, I rather follow
what trace_marker does and return -EBADF and not -EFAULT.
sunliming,
Care to send a v3 that returns -EBADF instead?
Thanks,
-- Steve
prev parent reply other threads:[~2023-06-26 6:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-23 19:29 Steven Rostedt
2023-06-23 23:21 ` Linus Torvalds
2023-06-24 2:09 ` Steven Rostedt
2023-06-24 17:50 ` Steven Rostedt
2023-06-25 23:04 ` Linus Torvalds
2023-06-26 6:07 ` Steven Rostedt [this message]
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=20230626020731.299d0b10@rorschach.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=beaub@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=sunliming@kylinos.cn \
--cc=torvalds@linux-foundation.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
all inboxes | Powered by JetHome®