From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Tao Chen <chen.dylane@gmail.com>,
mhiramat@kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: Add WARN_ON_ONCE for syscall_nr check
Date: Thu, 28 Nov 2024 11:52:26 -0500 [thread overview]
Message-ID: <20241128115226.504e7563@rorschach.local.home> (raw)
In-Reply-To: <67b5a0d7-95a2-46d2-bb4a-69a4368abe3d@efficios.com>
On Thu, 28 Nov 2024 11:02:31 -0500
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> > A better solution is for there to be a return code or something where the
> > tracers (perf or ftrace) can record in the trace that the system call is
> > not supported.
>
> Just be careful not to spam the traces uselessly. E.g. if only the
> openat syscall is enabled, you'd only want to be made aware of the
> ia32 openat, not all ia32 syscalls.
Why not? If you ask to trace something that isn't able to be traced,
add something in the buffer. It's not totally useless information. If
anything, you know that a task is making ia32 system calls, and how
many and when they are doing so.
Why make it more complex than it has to be. To do it only once, you
need to add the accounting logic to make sure each trace gets notified
about it. Not to mention if the event gets dropped.
If the user doesn't want this in their buffer, then they should filter
it out.
-- Steve
next prev parent reply other threads:[~2024-11-28 16:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-28 11:53 [PATCH] tracing: Add WARN_ON_ONCE for syscall_nr check Tao Chen
2024-11-28 12:46 ` Steven Rostedt
2024-11-28 13:15 ` Tao Chen
2024-11-28 14:27 ` Mathieu Desnoyers
2024-11-29 2:48 ` Tao Chen
2024-11-28 15:03 ` Steven Rostedt
2024-11-28 16:02 ` Mathieu Desnoyers
2024-11-28 16:52 ` Steven Rostedt [this message]
2024-11-29 2:51 ` Tao Chen
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=20241128115226.504e7563@rorschach.local.home \
--to=rostedt@goodmis.org \
--cc=chen.dylane@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).