On Tue, Sep 8, 2026 at 1:24 AM Leon Hwang <[email protected]> wrote: > > 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.
Good point. I agree. I'll send a patch with this approach instead. Thanks.
