The addition of more use of bpf_prog_info for gather BPF metadata in: https://lore.kernel.org/all/20250612194939.162730-1-blakejones@xxxxxxxxxx/ and the ever richer perf trace testing, such as: https://lore.kernel.org/all/20250528191148.89118-1-howardchu95@xxxxxxxxx/ frequently triggered a latent perf bug in v6.17 when the perf and libbpf updates came together. The bug would cause segvs and was reported here: https://lore.kernel.org/lkml/CAP-5=fWJQcmUOP7MuCA2ihKnDAHUCOBLkQFEkQES-1ZZTrgf8Q@xxxxxxxxxxxxxx/ To fix the issue the 1st and 3rd patch are necessary. Both patches address a race of either the sideband thread updating perf's state or the kernel state changing over two system calls. The use-after-free was introduced by: https://lore.kernel.org/r/20241205084500.823660-4-quic_zhonhan@xxxxxxxxxxx The lack of failing getting the bpf_prog_info for changes in the kernel was introduced in: https://lore.kernel.org/r/20211011082031.4148337-4-davemarchevsky@xxxxxx As v6.17 is currently actively segv-ing in perf test I'd recommend these patches go into v6.17 asap. When running the perf tests on v6.17 I frequently see less critical test failures addressed in: https://lore.kernel.org/all/20250821221834.1312002-1-irogers@xxxxxxxxxx/ Ian Rogers (3): perf bpf-event: Fix use-after-free in synthesis perf bpf-utils: Constify bpil_array_desc perf bpf-utils: Harden get_bpf_prog_info_linear tools/perf/util/bpf-event.c | 39 ++++++++++++++++-------- tools/perf/util/bpf-utils.c | 61 ++++++++++++++++++++++++------------- 2 files changed, 66 insertions(+), 34 deletions(-) -- 2.51.0.355.g5224444f11-goog