linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Beau Belgrave <beaub@linux.microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 02/10] user_events: Add minimal support for trace_event into ftrace
Date: Wed, 10 Nov 2021 22:56:30 +0900	[thread overview]
Message-ID: <20211110225630.babcd70ec85f97e369b0e446@kernel.org> (raw)
In-Reply-To: <20211109190844.GA1529@kbox>

On Tue, 9 Nov 2021 11:08:44 -0800
Beau Belgrave <beaub@linux.microsoft.com> wrote:

> > > I'd like to know if I do fix them that the features like filtering will still
> > > be available to user_events or if it's better to just add flags to disable
> > > kernel filtering?
> > 
> > I would rather like that the filters will be available on the user_events.
> > 
> > My question is that you need to log the dynamic data or strings via user-
> > events or not. Since the other user-events, like SDT doesn't support the
> > string variables to trace, I guess that is not a high priority.
> > 
> > Moreover, since now we can use eprobes, if user event records the address of
> > user-string, the eprobes can fetch it.
> > 
> > So, my suggestion is implmenting with fixed-size parameters as the first step
> > and keep filter/histograms/eprobes available on the user-events.
> > If you find any performance issue, you can expand the user-events to support
> > dynamic (array) data and strings.
> > 
> 
> We need strings to be able to be emitted and recorded in eBPF, perf and
> ftrace. So I would rather go after a solution that lets us keep these in
> the ring buffers, even if it means a perf hit.

OK, my concern is based on the current implementation, so in that case
you can add some additional verification. That is good.

> Guess what's left is to where the best place to check is, checking in
> the filter with unsafe flags would let us keep most of the perf (we just
> check the undersize case, 1 branch). When these unsafe types are
> filtered then a perf tax is imposed to keep things safe.

I would like to keep verifying in writer side then we can ensure the
data on ring buffer (of perf and of ftrace) is sane. If you add the unsafe
flag, you have to change all the code which access the ring buffer, not only
the filter but also eprobes, histograms, perf-tools, and other user-space
tracing tools which reads the tracing buffer directly.

> It sounded like Steven wanted to think about this a bit, so I'll wait a
> bit before poking again for consensus :)
> 
> Do you have any strong feelings about where it goes?

I recommend you to start verifying the writer side, it should make the
change as small as possible. Unsafe flag idea may involve many other
tools. And it is not fundamentary required for user-events.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

  parent reply	other threads:[~2021-11-10 13:56 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 17:04 [PATCH v4 00/10] user_events: Enable user processes to create and write to trace events Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 01/10] user_events: Add UABI header for user access to user_events Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 02/10] user_events: Add minimal support for trace_event into ftrace Beau Belgrave
2021-11-04 21:34   ` kernel test robot
2021-11-08  2:32     ` Masami Hiramatsu
2021-11-08 16:59       ` Beau Belgrave
2021-11-07 14:31   ` Masami Hiramatsu
2021-11-08 17:13     ` Beau Belgrave
2021-11-08 18:16       ` Steven Rostedt
2021-11-08 20:25         ` Beau Belgrave
2021-11-08 21:00           ` Steven Rostedt
2021-11-08 22:09             ` Beau Belgrave
2021-11-08 22:30               ` Steven Rostedt
2021-11-08 22:59                 ` Beau Belgrave
2021-11-09  4:58               ` Masami Hiramatsu
2021-11-09  2:56           ` Masami Hiramatsu
2021-11-09 19:08             ` Beau Belgrave
2021-11-09 19:25               ` Steven Rostedt
2021-11-09 20:14                 ` Beau Belgrave
2021-11-09 20:45                   ` Steven Rostedt
2021-11-09 21:27                     ` Beau Belgrave
2021-11-09 21:39                       ` Steven Rostedt
2021-11-10 13:56               ` Masami Hiramatsu [this message]
2021-11-11 17:33                 ` Beau Belgrave
2021-11-12 13:40                   ` Masami Hiramatsu
2021-11-07 18:18   ` Steven Rostedt
2021-11-08 19:56     ` Beau Belgrave
2021-11-08 20:53       ` Steven Rostedt
2021-11-08 21:15         ` Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 03/10] user_events: Add print_fmt generation support for basic types Beau Belgrave
2021-11-08 22:03   ` Steven Rostedt
2021-11-04 17:04 ` [PATCH v4 04/10] user_events: Handle matching arguments from dyn_events Beau Belgrave
2021-11-08 22:05   ` Steven Rostedt
2021-11-04 17:04 ` [PATCH v4 05/10] user_events: Add basic perf and eBPF support Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 06/10] user_events: Add self-test for ftrace integration Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 07/10] user_events: Add self-test for dynamic_events integration Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 08/10] user_events: Add self-test for perf_event integration Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 09/10] user_events: Optimize writing events by only copying data once Beau Belgrave
2021-11-08 22:45   ` Steven Rostedt
2021-11-08 23:00     ` Beau Belgrave
2021-11-08 23:04       ` Steven Rostedt
2021-11-08 23:17         ` Beau Belgrave
2021-11-08 23:20           ` Steven Rostedt
2021-11-04 17:04 ` [PATCH v4 10/10] user_events: Add documentation file Beau Belgrave
2021-11-04 19:05   ` Jonathan Corbet
2021-11-04 21:08     ` Beau Belgrave
2021-11-04 21:18       ` Jonathan Corbet

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=20211110225630.babcd70ec85f97e369b0e446@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=beaub@linux.microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=rostedt@goodmis.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).