Re: [RFC PATCH 0/4] ftrace: Add task comm filtering for function tracing

Steven wrote:

On Sun, 30 Aug 2026 19:07:43 +0800 (CST)
[off-list ref] wrote:

quoted

Hi Steven and Masami,

This series adds two comm-based task filters for the function and
function_graph tracers:

  set_ftrace_comm
  set_ftrace_notrace_comm

I'd like to avoid adding more files like this. If anything, I would love to
add triggers to the function tracers.

Agreed. Adding two more tracefs files may not be the best interface. Together
with the points raised in the earlier discussion with Masami, I also think a
trigger-based interface would be a cleaner direction.

quoted

Function tracing currently supports selecting tasks by PID. This makes
it difficult to configure tracing before a service starts, because it
does not have a PID yet. It is also inconvenient to keep tracing the
same service across restarts, as its PID may change. This use case was
suggested by Xuxin, a KSM reviewer.

I've always recommended a simple wrapper script for applications:

echo '#! /bin/bash
  echo $$ > /sys/kernel/tracing/set_ftrace_pid
  echo $$ > /sys/kernel/tracing/set_event_pid
  exec "$@"' > trace-me.sh

chmod +x trace-me.sh

  ./trace-me.sh command to be traced

The above will do what you want.

Yes, this works well when we have control over how the application is
launched. Thanks for the example!

But if we really do want to add more filters to function tracing, then
adding triggers to it would be the way to go.

Understood. To make sure I understand the proposed direction, here is a
conceptual example of what the interface might look like:

echo 'ftrace_pid_add if newcomm == "foo"' > \
 events/task/task_rename/trigger

When a task changes its comm to foo, the trigger would add the PID from
the task_rename event to the function tracer's PID filter. The function
and function_graph tracers would then trace that task using the existing
PID-filtering mechanism.

We may also need a corresponding ftrace_pid_remove trigger command to
remove the PID associated with the triggering event from the function
tracer's PID list.

The command names above are only illustrative. Is this roughly the kind of
trigger interface you had in mind?

If so, we will investigate extending the trigger infrastructure in this
direction instead of adding the comm-filter files.

--
With Best Regards,
Shengming