lkml.org 
[lkml]   [2021]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@linux.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

\
 
 \ /
  Last update: 2021-11-09 22:28    [W:0.352 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site