Re: [PATCH v5 perf, bpf-next 3/7] perf, bpf: introduce PERF_RECORD_BPF_EVENT
From: Peter Zijlstra <peterz@infradead.org>
Date: 2019-01-08 18:41:22
Also in:
lkml
On Thu, Dec 20, 2018 at 10:29:00AM -0800, Song Liu wrote:
quoted hunk ↗ jump to hunk
@@ -986,9 +987,35 @@ enum perf_event_type { */ PERF_RECORD_KSYMBOL = 17, + /* + * Record bpf events: + * enum perf_bpf_event_type { + * PERF_BPF_EVENT_UNKNOWN = 0, + * PERF_BPF_EVENT_PROG_LOAD = 1, + * PERF_BPF_EVENT_PROG_UNLOAD = 2, + * }; + * + * struct { + * struct perf_event_header header; + * u16 type; + * u16 flags; + * u32 id; + * u8 tag[BPF_TAG_SIZE]; + * struct sample_id sample_id; + * }; + */ + PERF_RECORD_BPF_EVENT = 18, +
Elsewhere today, I raised the point that by the time (however short interval) userspace gets around to reading this event, the actual program could be gone again. In this case the program has been with us for a very short period indeed; but it could still have generated some samples or otherwise generated trace data. It was suggested to allow pinning modules/programs to avoid this situation, but that of course has other undesirable effects, such as a trivial DoS. A truly horrible hack would be to include an open filedesc in the event that needs closing to release the resource, but I'm sorry for even suggesting that **shudder**. Do we have any sane ideas?