[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211109154520.11995e75@gandalf.local.home>
Date: Tue, 9 Nov 2021 15:45:20 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Beau Belgrave <beaub@...ux.microsoft.com>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
linux-trace-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 02/10] user_events: Add minimal support for
trace_event into ftrace
On Tue, 9 Nov 2021 12:14:32 -0800
Beau Belgrave <beaub@...ux.microsoft.com> wrote:
> The ftrace probe will have a blob even after optimization due to the copy
> into the ring buffer (assuming we can discard it if it violates a policy).
Yes it can be discarded. In fact, when filtering is enabled, it tries to
first use a temporary per cpu buffer to do the filtering and not write it
into the ring buffer. Only when it passes the filter does it get injected.
For user events that happen in user context, it will always use this temp
buffer. But since there's only buffer per CPU, if an interrupt comes in and
executes a filtered event, it will use the ring buffer itself, and discard
it if it does not match.
>
> > That is, the reading of the trace file?
> >
>
> We really need to ensure that data can be analyzed on the machine
> directly (eBPF, ftrace, perf) as well as outside of the machine (ftrace, perf).
>
> The priorities to us are fast recording speed with accurate reading of trace
> files and event data.
OK, then it probably isn't an issue to add checks to the parsing of the
dynamic arrays (including strings) that makes sure the string is within
bounds for the filtering.
-- Steve
Powered by blists - more mailing lists