Mai*_*ake 4 c bpf tracepoint ebpf
阅读一些附加到跟踪点的ebpf示例后,我注意到每个结构都是从这样的填充开始构建的(来自samples/bpf/xdp_redirect_cpu_kern.c)
/* Tracepoint: /sys/kernel/debug/tracing/events/xdp/xdp_cpumap_enqueue/format
* Code in: kernel/include/trace/events/xdp.h
*/
struct cpumap_enqueue_ctx {
u64 __pad; // First 8 bytes are not accessible by bpf code
int map_id; // offset:8; size:4; signed:1;
u32 act; // offset:12; size:4; signed:0;
int cpu; // offset:16; size:4; signed:1;
unsigned int drops; // offset:20; size:4; signed:0;
unsigned int processed; // offset:24; size:4; signed:0;
int to_cpu; // offset:28; size:4; signed:1;
};
Run Code Online (Sandbox Code Playgroud)
我发现的所有评论都是bpf代码无法访问前8个字节,但我不明白为什么。
从此邮件列表:
bpf代码无法访问跟踪点上下文结构的前8个字节。这种选择可以追溯到最初包含此代码。
请参阅以下内容中的解释:提交98b5c2c65c29(“ perf,bpf:允许bpf程序附加到跟踪点”)
introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be attached
to the perf tracepoint handler, which will copy the arguments into
the per-cpu buffer and pass it to the bpf program as its first argument.
The layout of the fields can be discovered by doing
'cat /sys/kernel/debug/tracing/events/sched/sched_switch/format'
prior to the compilation of the program with exception that first 8 bytes
are reserved and not accessible to the program. This area is used to store
the pointer to 'struct pt_regs' which some of the bpf helpers will use:
+---------+
| 8 bytes | hidden 'struct pt_regs *' (inaccessible to bpf program)
+---------+
| N bytes | static tracepoint fields defined in tracepoint/format (bpf readonly)
+---------+
| dynamic | __dynamic_array bytes of tracepoint (inaccessible to bpf yet)
+---------+
Not that all of the fields are already dumped to user space via perf ring buffer
and broken application access it directly without consulting tracepoint/format.
Same rule applies here: static tracepoint fields should only be accessed
in a format defined in tracepoint/format. The order of fields and
field sizes are not an ABI.
Run Code Online (Sandbox Code Playgroud)
因此前8个字节不可访问,因为它们用于存储指向BPF帮助程序使用的关键结构的指针,因此需要保持隐藏状态以防止损坏或信息泄漏。