Hi all,
This patch adds the bpf_descendant_of helper which accepts a PID and
returns 1 if the PID of the process currently being executed is a
descendant of it or if it's itself. Returns 0 otherwise. The passed
PID should be the one as seen from the "global" pid namespace as the
processes' PIDs in the hierarchy are resolved using the context of said
initial namespace.
This is very useful in tracing programs when we want to filter by a
given PID and all the children it might spawn. The current workarounds
most people implement for this purpose have issues:
- Attaching to process spawning syscalls and dynamically add those PIDs
to some bpf map that would be used to filter is cumbersome and
potentially racy.
- Unrolling some loop to perform what this helper is doing consumes lots
of instructions. That and the impossibility to jump backwards makes it
really hard to be correct in really large process chains.
Let me know what do you think!
Thanks,
---
Changes in V6:
- Small style fix
- Clarify in the docs that we are resolving PIDs using the global,
initial PID namespace, and the provided *pid* argument should be global, too
- Changed the way we assert on the helper return value
Changes in V5:
- Addressed code review feedback
- Renamed from progenyof => descendant_of as suggested by Jon Haslam
and Brendan Gregg
Changes in V4:
- Rebased on latest bpf-next after merge window
Changes in V3:
- Removed RCU read (un)locking as BPF programs alredy run in RCU locked
context
- progenyof(0) now returns 1, which, semantically makes more sense
- Added new test case for PID 0 and changed sentinel value for errors
- Rebase on latest bpf-next/master
- Used my work email as somehow I accidentally used my personal one in
v2
Changes in V2:
- Adding missing docs in include/uapi/linux/bpf.h
--
2.17.1
