阅读一些附加到跟踪点的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;
};
我发现的只是这条评论，它说前 8 个字节不能通过 bpf 代码访问，但我不明白为什么。
从这个邮件列表中：
跟踪点上下文结构的前 8 个字节无法通过 bpf 代码访问。 这是一个可以追溯到最初包含此代码的选择。
请参阅以下解释：提交 98b5c2c65c29("perf， bpf：允许 bpf 程序附加到跟踪点"(
从提交 98b5c2c65c29：
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.
因此，前 8 个字节无法访问，因为它们用于存储指向 BPF 帮助程序使用的关键结构的指针，因此需要保持隐藏以防止损坏或信息泄漏。