On Tue, Feb 23, 2021 at 7:07 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
>
> Forwarding this to the mailing list, as well. Any discussions on this may
> be easier to discuss here than on the bugzilla.
>
> -- Steve
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=210643
>
> --- Comment #7 from Steven Rostedt (rostedt@xxxxxxxxxxx) ---
> After some discussions on the mailing lists, I found that it is important to
> establish the requirements that I expect of this API. I'm doing it in the
> bugzilla instead of the mailing list (but will also forward this to the
> mailing list), as this is more about the feature request and not about the
> development of it.
>
> The prototype should be:
>
> int tracefs_function_filter(struct tracefs_instance *instance,
> const char * const *filters,
> const char *module,
> boolean reset);
I think there should be a complementary API for deleting the filters,
may be something like
int tracefs_function_filter_remove(struct tracefs_instance *instance,
const char *
const *filters,
const char *module)
It should be able to remove the filters, configured by the first API
with the same "filters, module" input parameters.
>
> If @instance is NULL, the filter for the top level tracing directory is
> used. Otherwise the filter is for the given instance.
>
> The @filters is an array of strings that holds one or more filters, and the
> array ends with a NULL pointer.
>
> If @module is set, only apply the filter to functions for a given module.
> This is ignored if NULL is passed in. I added this to the interface because
> it is commonly used, and the set_ftrace_filter has a special way to handle
> it (see more below).
>
> If @reset is set, the function filter for the given instance (or toplevel if
> @instance is NULL), is cleared before applying the new filter functions.
> Otherwise, the function filters are appended.
>
> Note on reset being set: This is an important implementation detail. The
> reset must be done by opening the file with O_WRONLY|O_TRUNC set. And the
> file is not closed until all the new filters are added. It must not clear
> the file and close it before setting the new filters. The reason is, if it
> does, then all functions will start to be traced!
>
> If the function filter has some functions in set_ftrace_filter, and the
> function tracer is active, then it is only tracing those functions in
> set_ftrace_filter. If you want to change that set of functions to a new set,
> you open the set_ftrace_filter file with O_WRONLY|O_TRUNC and add your new
> functions. On closing the file, the change takes place. The old functions
> being filtered will no longer be traced, and the new functions being filter
> will start to be traced.
>
> If the set_ftrace_filter is truncated and closed without setting the new
> functions, then the function tracer will start tracing *all* functions!
> That is not what this API should do. This is why it is important that you
> write the new filters after opening with O_TRUNC and before closing the
> file descriptor. This is another reason to use an array of filters instead
> of having the application call this function multiple times with different
> filters strings.
>
> Now when writing the filters, the following should be done for each filter.
> Write the filter to set_ftrace_filter file, and if it succeeds, then
> continue to the next filter. If it does not succeed, then check if it is a
> regex. If so, then add all the functions that match the regex that are in
> available_filter_functions.
>
> Note, if @module is not NULL, then before writing the filter strings for the
> non regex write, append ":mod:@module" to each filter string. That is, if
> @module is "bridge" and the filter is "br_*", then what should be written
> into the set_ftrace_filter file is: "br_*:mod:bridge", and the kernel will
> only apply the "br_*" to the module "bridge". Implementation detail, you
> can simply write the filter unmodified, then write ":mod:" then write
> "bridge", before writing any spaces to separate the filters. The kernel
> will process that as one string "br_*:mod:bridge". This way the function
> does not need to worry about allocating extra memory and copying the string
> to append the ":mod:bridge" before writing.
>
> If a regex is used, then the search of available_filter_functions should
> only look for function names that have the module name behind it. That is,
> if @module is "bridge" and the filter is ".*switchdev_\\(port\\|fdb\\).*",
> and @module is set, then the search over available_filter_functions should
> run the regex only on functions that have a matching module name "[bridge]".
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You reported the bug.
> You are watching the assignee of the bug.
> You are watching the reporter of the bug.
--
Tzvetomir (Ceco) Stoyanov
VMware Open Source Technology Center
|