From: Shengming Hu <hu.shengming@zte.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