[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211109212756.GA1741@kbox>
Date: Tue, 9 Nov 2021 13:27:56 -0800
From: Beau Belgrave <beaub@...ux.microsoft.com>
To: Steven Rostedt <rostedt@...dmis.org>
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, Nov 09, 2021 at 03:45:20PM -0500, Steven Rostedt wrote:
> 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
Where were you thinking the filtering would occur? In the filter /
histogram predicates or in user_events directly before buffer commit?
Thanks,
-Beau
Powered by blists - more mailing lists