On 2026/9/7 13:46, Thiébaud Weksteen wrote: > On Fri, Sep 4, 2026 at 4:07 PM Leon Hwang <[email protected]> wrote: >> >> On 4/9/26 11:19, Thiébaud Weksteen wrote: >>> Commit 4c9241bd731a ("selftests/bpf: Add tests to verify global percpu >>> data") added test_global_percpu_data.c to LSKELS_EXTRA. Later, in commit >>> 1ed2294b31fc ("selftests/bpf: Test verifier log for global percpu data") >>> two verifier failure tests were added (verifier_strncmp and >>> verifier_snprintf), both marked as non-autoload (SEC("?kprobe")). >>> >>> When bpftool generates light skeletons, non-autoloaded programs are >>> skipped during loading, causing the loader program to store subsequent >>> program FDs into incorrect skeleton struct fields (e.g. dump_percpu_data's >>> FD was stored into verifier_strncmp's descriptor). >> >> IIUC, patch 2 will fix the issue totally. >> >> Better to add a subtest to verify both the issue and the fix? > > Thanks for the review. That's right, patch 2 will fix the issue: > bpftool will fail to build any program that is set up that way. That's > why patch 1 is necessary; otherwise, the existing test would fail. > > Just checking your suggestion: what I can do is add a new test to make > sure that dump_percpu_data is set up as expected (fd > 0). I can write > a new test_global_percpu_data_iter_lskel, that is similar to > test_global_percpu_data_iter, but for lskel? > > I can also write a test to ensure that bpftool fails when light > skeletons are set up with autoload=false? >
imo, the rejection of autoload=false prog when generating light skeleton is not friendly for users. Users should not care about mixing autoload=false progs with autoload=true progs, even for light skeletons. The users-friendly way is to skip those autoload=false progs when generating light skeletons. So, this is a bpftool issue. A selftest is unnecessary. You can verify both the issue and the fix manually. Probably, paste the verification result in the patch message. Thanks, Leon
