perf: why does the reader return more data than was submitted from BPF?

[llhhbc]

ctx_event_output(ctx, &EVENTS_MAP,
			 (cap_len << 32) | BPF_F_CURRENT_CPU,
			 &msg, sizeof(msg));

this code send msg is only 48. but read from pref is bigger than.
Here is my debug msg:

[root@c7-1 ~]# grep "0403770e5ca262d6760000007600010029" pref.log
level=debug msg="read perf info. " cpu=7 lost_samples=0 raw_sample=0403770e5ca262d6760000007600010029aa000001000000000002000000000000000000000000000000000000000000a63ad35377033ee448c183300800451000688b3540003f06570bab000171ab0001ce0016b7b63453affedcc4c2b2801801f5599a00000101080a10b5957c3498e507449240e6c91a8f185305bf7b61a3e99caeaa8007f64fa8134b11ecccbac3f6210891ff4e9ebba77d5c57863f4474be7f79a01c31dc6bab0001dc startTime="2023-03-09 13:25:21.031667369 +0000 UTC m=+11.832516899" subsys=monitor-agent
[root@c7-1 ~]# grep "0405770e5ca262d66600000066" pref.log
level=debug msg="read perf info. " cpu=1 lost_samples=0 raw_sample=0405770e5ca262d6660000006600010029aa000000000000000005000000000000000000000000000000000000000000a63ad35377033ee448c183300800451000588b3640004006561aab000171ab0001ce0016b7b63453b032dcc4c2d6801801f5598a00000101080a10b598973498e8215c4b8a49d14d84b46401b8fe22c0ed6354ecae4522b264b57c84a1aa7bca647da454a336000000000500 startTime="2023-03-09 13:25:21.031667369 +0000 UTC m=+11.832516899" subsys=monitor-agent

[ti-mo]

Hey @llhhbc, this is indeed a great question. :) Depending on the size of the input passed to perf_event_output in your BPF program, there can be between 0 and 7 extra bytes at the end of perf event records. The kernel aligns the event header (4 bytes) plus the input to 64 bits, but the []byte returned from Reader.Read() won't include the header. This means you can expect slices of length 4, 12, 20, 28 etc. bytes depending on the length of your input.

Note that the padding bytes are not cleared, so once the ring wraps the page boundary, you'll start seeing garbage show up where there were zeroes before. This behaviour is documented on Record.RawSample. I've sent a patch upstream to zero the padding, but not sure it'll make it in.

tl;dr: what you're seeing is normal, the trailing data is safe to ignore. See this thread for more info: #94 (comment).

[llhhbc]

I see, thank you very much for your reply