Hi, Thank you for the review.
You are completely right regarding wq__open_and_load(): if it fails, it returns NULL and performs its own cleanup, so an immediate return is correct there. However, my concern is about the next step: wq__attach(wq_skel). If wq__open_and_load() succeeds, wq_skel is allocated. If wq__attach() subsequently fails, the original code returns immediately without calling wq__destroy(wq_skel), which causes a memory leak of the skeleton object. The proposed goto clean_up is intended to ensure wq__destroy(wq_skel) is called specifically when wq__attach() fails. Does that make sense? Best regards, Kery Yonghong Song <[email protected]> 于2026年1月21日周三 23:45写道： > > > > On 1/21/26 1:41 AM, Kery Qi wrote: > > When wq__attach() fails, serial_test_wq() returns early without calling > > wq__destroy(), leaking the skeleton resources allocated by > > wq__open_and_load(). This causes ASAN leak reports in selftests runs. > > > > Fix this by jumping to a common clean_up label that calls wq__destroy() > > on all exit paths after successful open_and_load. > > > > Note that the early return after wq__open_and_load() failure is correct > > and doesn't need fixing, since that function returns NULL on failure > > (after internally cleaning up any partial allocations). > > > > Fixes: 8290dba51910 ("selftests/bpf: wq: add bpf_wq_start() checks") > > Signed-off-by: Kery Qi <[email protected]> > > Acked-by: Yonghong Song <[email protected]> >
