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

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.

The new filters match task comm names exactly. When both PID and comm 
include filters are active, a task must match both to be traced. A
match in either the PID or comm notrace filter excludes the task.

To avoid string matching in the function tracing fast path, the filters
are evaluated when a task is scheduled in. The result is stored in the
existing per-CPU cache used by PID filtering. Changing a filter refreshes
the cached result for currently running tasks. If a task's comm changes,
the new name is used the next time the task is scheduled in.

The first two patches prepare the existing PID-filtering infrastructure
by using general task-filter names and centralizing sched_switch probe
registration and per-CPU cache updates. The third patch adds the comm
filters, and the final patch documents their interface and interaction
with PID filters.

This is an RFC intended to discuss whether comm-based task filtering is
a useful direction for function tracing and whether this interface would
be suitable for eventual upstream inclusion. Additional selftests are
planned for the next revision. Feedback on the overall approach and
interface would be greatly appreciated.

Thanks,
Shengming

Shengming Hu (4):
  ftrace: Generalize function task filter names
  ftrace: Centralize task filter state updates
  ftrace: Add exact task comm filtering
  Documentation/ftrace: Document function comm filters

 Documentation/trace/ftrace.rst |  31 +++
 include/linux/ftrace.h         |   4 +-
 kernel/trace/Makefile          |   1 +
 kernel/trace/comm_list.c       | 314 +++++++++++++++++++++++++
 kernel/trace/comm_list.h       |  17 ++
 kernel/trace/fgraph.c          |   4 +-
 kernel/trace/ftrace.c          | 402 ++++++++++++++++++++++++++++++---
 kernel/trace/trace.c           |   5 +
 kernel/trace/trace.h           |  34 ++-
 kernel/trace/trace_events.c    |  16 +-
 kernel/trace/trace_functions.c |   2 +-
 kernel/trace/trace_pid.c       |   8 +-
 12 files changed, 791 insertions(+), 47 deletions(-)
 create mode 100644 kernel/trace/comm_list.c
 create mode 100644 kernel/trace/comm_list.h

-- 
2.25.1

On Sun, 30 Aug 2026 19:07:43 +0800 (CST)
<hu.shengming@zte.com.cn> wrote:

> 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.

> 
> 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.

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

-- Steve

Steven wrote:

> On Sun, 30 Aug 2026 19:07:43 +0800 (CST)
> <hu.shengming@zte.com.cn> wrote:
> 
> > 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.

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

On Sun, 30 Aug 2026 19:07:43 +0800 (CST)
<hu.shengming@zte.com.cn> wrote:

> 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
> 
> 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.

Thanks for the idea. I thought we can use `pidof` but it is for running
processes.

> 
> The new filters match task comm names exactly. When both PID and comm 
> include filters are active, a task must match both to be traced. A
> match in either the PID or comm notrace filter excludes the task.
> 
> To avoid string matching in the function tracing fast path, the filters
> are evaluated when a task is scheduled in. The result is stored in the
> existing per-CPU cache used by PID filtering. Changing a filter refreshes
> the cached result for currently running tasks. If a task's comm changes,
> the new name is used the next time the task is scheduled in.

OK, but can trace scheduler event (or add a new event) that we just convert
comm to PID when the comm is changed and add/remove it to pid filter?
If that works, we can also extend generic event trigger to set ftrace pid
filter. Using this allows you to add or remove processes as ftrace targets
at runtime—not only based on comm, but for other reasons as well.
(of course, setting per-cpu cache requires to kick a worker...)

This will leak the pid via set_ftrace_pid, but that is good from the
monitoring point of view.

Thank you,

> 
> The first two patches prepare the existing PID-filtering infrastructure
> by using general task-filter names and centralizing sched_switch probe
> registration and per-CPU cache updates. The third patch adds the comm
> filters, and the final patch documents their interface and interaction
> with PID filters.
> 
> This is an RFC intended to discuss whether comm-based task filtering is
> a useful direction for function tracing and whether this interface would
> be suitable for eventual upstream inclusion. Additional selftests are
> planned for the next revision. Feedback on the overall approach and
> interface would be greatly appreciated.
> 
> Thanks,
> Shengming
> 
> Shengming Hu (4):
>   ftrace: Generalize function task filter names
>   ftrace: Centralize task filter state updates
>   ftrace: Add exact task comm filtering
>   Documentation/ftrace: Document function comm filters
> 
>  Documentation/trace/ftrace.rst |  31 +++
>  include/linux/ftrace.h         |   4 +-
>  kernel/trace/Makefile          |   1 +
>  kernel/trace/comm_list.c       | 314 +++++++++++++++++++++++++
>  kernel/trace/comm_list.h       |  17 ++
>  kernel/trace/fgraph.c          |   4 +-
>  kernel/trace/ftrace.c          | 402 ++++++++++++++++++++++++++++++---
>  kernel/trace/trace.c           |   5 +
>  kernel/trace/trace.h           |  34 ++-
>  kernel/trace/trace_events.c    |  16 +-
>  kernel/trace/trace_functions.c |   2 +-
>  kernel/trace/trace_pid.c       |   8 +-
>  12 files changed, 791 insertions(+), 47 deletions(-)
>  create mode 100644 kernel/trace/comm_list.c
>  create mode 100644 kernel/trace/comm_list.h
> 
> -- 
> 2.25.1


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Masami wrote:

> On Sun, 30 Aug 2026 19:07:43 +0800 (CST)
> <hu.shengming@zte.com.cn> wrote:
> 
> > 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
> > 
> > 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.
> 
> Thanks for the idea. I thought we can use `pidof` but it is for running
> processes.
> 

Yes, exactly. The main use case is to configure tracing before the
target task starts, when there is no PID for pidof to return. Thanks,
Xuxin! :)

> > 
> > The new filters match task comm names exactly. When both PID and comm 
> > include filters are active, a task must match both to be traced. A
> > match in either the PID or comm notrace filter excludes the task.
> > 
> > To avoid string matching in the function tracing fast path, the filters
> > are evaluated when a task is scheduled in. The result is stored in the
> > existing per-CPU cache used by PID filtering. Changing a filter refreshes
> > the cached result for currently running tasks. If a task's comm changes,
> > the new name is used the next time the task is scheduled in.
> 
> OK, but can trace scheduler event (or add a new event) that we just convert
> comm to PID when the comm is changed and add/remove it to pid filter?
> If that works, we can also extend generic event trigger to set ftrace pid
> filter. Using this allows you to add or remove processes as ftrace targets
> at runtime—not only based on comm, but for other reasons as well.
> (of course, setting per-cpu cache requires to kick a worker...)
> 
> This will leak the pid via set_ftrace_pid, but that is good from the
> monitoring point of view.
> 
> Thank you,
> 

Thank you for the suggestion!

My understanding is that, instead of adding comm-specific function
filters, we could add generic event-trigger actions that update the
existing function PID filter.

For example, the task_rename event already observes task comm changes.
Conceptually, a user could configure something like:

  ftrace_pid_add:pid if newcomm == "foo"
  ftrace_pid_del:pid if oldcomm == "foo" && newcomm != "foo"

The command names and syntax above are only examples. The PID field
would be selected from the event record, so the same actions could be
used with other events and filters, rather than being tied to comm or
task_rename.

I think the trigger actions could update the same PID list used by
set_ftrace_pid. A PID added by a trigger would then become a normal
set_ftrace_pid entry and would be visible when the file is read. The
list would be shared state, without tracking whether an entry came from
a user or a particular trigger. Removing a trigger would stop future
updates but would not roll back PIDs that it had already added.

Since an event trigger may run in a context where the PID list and
per-CPU cache cannot be updated directly, the trigger could queue the
operation to a worker. The worker would update the PID list and refresh
the cached task-filter result.

For the comm use case, a delete action on task_rename would remove a PID
when the task no longer has the selected comm. A delete action on
sched_process_exit could also remove stale PIDs when matching tasks
exit.

This would primarily support rules installed before a task starts or
before the relevant event occurs. It would not discover tasks that
already match when the trigger is installed unless they generate the
event again.

Does this shared PID-list and generic add/delete trigger model match
what you had in mind?

--
With Best Regards,
Shengming