Re: [PATCH v3 bpf-next 0/6] bpf: Unwinding with unwind_goto and unwind_exit

[Wang Yibo <szwyb123@gmail.com>]

Hi Alexei,

I tested v3 on arm64. The cover letter says test_progs was only run on
x86-64 and freplace was not run on arm64, so that is the part I tried to
cover.

The tree is bpf-next master b71326388a (7.3.0-rc5) with 0/6 applied on
top. All six patches applied without conflicts, 18 files changed,
+397/-6. Built for arm64 with gcc 15.2 from defconfig plus
selftests/bpf/config, config.aarch64 and config.vm, with
BPF_JIT_ALWAYS_ON=y. test_progs runs in a qemu guest under KVM, 8G and
4 cpus.

Results:

- verifier_unwind: 41/41 OK, no skips. The jit subtest passes too, so
  unwind_goto and unwind_exit are checked against the arm64 JIT output
  and not only in the verifier.
- unwind_attach: OK. freplace_returns returns 9, freplace_unwinds
  returns 13, and attaching freplace_unwinds to global_never_unwinds is
  rejected with the expected message while the target still returns 15.
- unwind_cxx: OK. Stock clang skips this one because the lowering is
  still in review (LLVM PR 233649), so I built clang from that PR to run
  it. catches/does_not_catch and the aggregate_return case pass on
  arm64, including the destructor order and the u128 return in R0:R2.
- Regression: test_bpffs, global_funcs and exceptions, 148 subtests, no
  failures. data_in_arena is 8/8, including the rust prog.

Two things from the setup that took me a while, in case they are worth a
note somewhere:

- the jit subtest is skipped silently when test_progs is built without
  llvm-dev, because the disassembly helper comes from the LLVM C API. A
  line in the commit message, or a skip message that names the missing
  library, would save the next person the bisect.
- bpf_testmod needs pahole 1.32 or newer on this tree. With 1.30 the
  three i128 kfuncs get no BTF func entry, their ids stay zero, and the
  module fails to load with -22 with nothing in dmesg. Unrelated to this
  series, but it looks like a verifier bug until the build log is found.

I only ran with BPF_JIT_ALWAYS_ON, so the JIT-disabled path reported
earlier in this thread is not covered by my run.

Feel free to add:

Tested-by: Wang Yibo <szwyb123@gmail.com>

Thanks,
Wang Yibo