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@xxxxxxxxxxxxxxxxxxx> 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