[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <202511261708240123PvauPcd7Xbqx_EDrKkNn@zte.com.cn>
Date: Wed, 26 Nov 2025 17:08:24 +0800 (CST)
From: <wang.yaxin@....com.cn>
To: <rostedt@...dmis.org>, <mhiramat@...nel.org>, <mark.rutland@....com>,
<mathieu.desnoyers@...icios.com>
Cc: <linux-kernel@...r.kernel.org>, <linux-trace-kernel@...r.kernel.org>,
<hu.shengming@....com.cn>, <zhang.run@....com.cn>,
<yang.yang29@....com.cn>, <wang.yaxin@....com.cn>
Subject: [PATCH v2 0/3] fgraph: Fix and tighten PID filtering support
From: Shengming Hu <hu.shengming@....com.cn>
Function graph tracing did not honor set_ftrace_pid() rules properly.
The root cause is that for fgraph_ops, the underlying ftrace_ops->private
was left uninitialized. As a result, ftrace_pids_enabled(op) always
returned false, effectively disabling PID filtering in the function graph
tracer.
PID filtering seemed to "work" only because graph_entry() performed an
extra coarse-grained check via ftrace_trace_task(). Specifically,
ftrace_ignore_pid is updated by ftrace_filter_pid_sched_switch_probe
during sched_switch events. Under the original logic, when the intent
is to trace only PID A, a context switch from task B to A sets
ftrace_ignore_pid to A’s PID. However, there remains a window
where B’s functions are still captured by the function-graph tracer.
The following trace demonstrates this leakage
(B = haveged-213, A = test.sh-385):
4) test.sh-385 | | set_next_entity() {
4) test.sh-385 | 2.108 us | __dequeue_entity();
4) test.sh-385 | 1.526 us | __update_load_avg_se();
4) test.sh-385 | 1.363 us | __update_load_avg_cfs_rq();
4) test.sh-385 | + 14.144 us | }
4) test.sh-385 | 1.417 us | __set_next_task_fair.part.0();
4) test.sh-385 | + 77.877 us | }
4) test.sh-385 | | __traceiter_sched_switch() {
4) test.sh-385 | 2.097 us | _raw_spin_lock_irqsave();
4) test.sh-385 | 1.483 us | _raw_spin_unlock_irqrestore();
4) test.sh-385 | + 14.014 us | }
------------------------------------------
4) test.sh-385 => haveged-213
------------------------------------------
4) haveged-213 | | switch_mm_irqs_off() {
4) haveged-213 | 2.387 us | choose_new_asid();
4) haveged-213 | + 12.462 us | switch_ldt();
4) haveged-213 | + 45.288 us | }
4) haveged-213 | 1.639 us | x86_task_fpu();
4) haveged-213 | | save_fpregs_to_fpstate() {
4) haveged-213 | 1.888 us | xfd_validate_state();
4) haveged-213 | 6.995 us | }
------------------------------------------
4) haveged-213 => test.sh-385
------------------------------------------
4) test.sh-385 | | finish_task_switch.isra.0() {
4) test.sh-385 | 1.857 us | _raw_spin_unlock();
4) test.sh-385 | 5.618 us | }
4) test.sh-385 | ! 446.226 us | }
4) test.sh-385 | | __pte_offset_map_lock() {
4) test.sh-385 | | ___pte_offset_map() {
4) test.sh-385 | 1.933 us | __rcu_read_lock();
4) test.sh-385 | 6.271 us | }
4) test.sh-385 | 2.056 us | _raw_spin_lock();
4) test.sh-385 | + 14.281 us | }
The following three logically independent patches fix this defect while
preserving the effectiveness of PID filtering in fgraph:
Patch 1 properly initializes ops->private for fgraph_ops.
Patch 2 switches gops->entryfunc to fgraph_pid_func when PID filtering
is active.
Patch 3 removes the coarse fallback logic, making PID filtering reliable
and consistent with function tracing.
Changes from v1:
https://lore.kernel.org/linux-trace-kernel/20251113135627439rGwzvG7JzdmnN8VMHAfMs@zte.com.cn/
- Split the patch into three independent commits as suggested by Steven
- Add a space after "ftrace_graph_active++" as suggested by Steven
Shengming Hu (3):
fgraph: Initialize ftrace_ops->private for function graph ops
fgraph: Check ftrace_pids_enabled on registration for early filtering
fgraph: fgraph: Remove redundant PID filtering from graph_entry()
kernel/trace/fgraph.c | 10 ++++++++--
kernel/trace/trace.h | 9 ---------
kernel/trace/trace_functions_graph.c | 3 ---
3 files changed, 8 insertions(+), 14 deletions(-)
--
2.25.1
Powered by blists - more mailing lists