On Thu, 2024-07-11 at 16:19 -0700, Eduard Zingerman wrote:
[...]
> While re-testing the patch I've noticed a strange behaviour:
> $ cd <kernel>/tools/testing/selftests/bpf
> $ git clean -xfd .
> $ make -j14
> $ touch progs/atomics.c
> $ make -j14 test_progs
> CLNG-BPF [test_maps] atomics.bpf.o
> CLNG-BPF [test_maps] atomics.bpf.o
> CLNG-BPF [test_maps] atomics.bpf.o
> GEN-SKEL [test_progs] atomics.lskel.h
> GEN-SKEL [test_progs-cpuv4] atomics.lskel.h
> GEN-SKEL [test_progs-no_alu32] atomics.lskel.h
> TEST-OBJ [test_progs] arena_htab.test.o
> TEST-OBJ [test_progs] atomics.test.o
> ... many lines ...
> TEST-OBJ [test_progs] uprobe_multi_test.test.o
> TEST-OBJ [test_progs] usdt.test.o
> TEST-OBJ [test_progs] verify_pkcs7_sig.test.o
> TEST-OBJ [test_progs] vmlinux.test.o
> TEST-OBJ [test_progs] xdp_adjust_tail.test.o
> TEST-OBJ [test_progs] xdp_metadata.test.o
> TEST-OBJ [test_progs] xdp_synproxy.test.o
> BINARY test_progs
> 16:15:34 bpf$ make -j14 test_progs
> TEST-OBJ [test_progs] bpf_iter.test.o
> TEST-OBJ [test_progs] bpf_nf.test.o
> TEST-OBJ [test_progs] bpf_obj_id.test.o
> TEST-OBJ [test_progs] btf.test.o
> TEST-OBJ [test_progs] btf_write.test.o
> TEST-OBJ [test_progs] cgrp_local_storage.test.o
> TEST-OBJ [test_progs] iters.test.o
> TEST-OBJ [test_progs] lsm_cgroup.test.o
> TEST-OBJ [test_progs] send_signal.test.o
> TEST-OBJ [test_progs] sockmap_basic.test.o
> TEST-OBJ [test_progs] sockmap_listen.test.o
> TEST-OBJ [test_progs] trace_vprintk.test.o
> TEST-OBJ [test_progs] usdt.test.o
> TEST-OBJ [test_progs] xdp_metadata.test.o
> BINARY test_progs
> 16:15:37 bpf$ make -j14 test_progs
> TEST-OBJ [test_progs] bpf_obj_id.test.o
> TEST-OBJ [test_progs] sockmap_listen.test.o
> TEST-OBJ [test_progs] xdp_metadata.test.o
> BINARY test_progs
> 16:15:39 bpf$ make -j14 test_progs
> TEST-OBJ [test_progs] sockmap_listen.test.o
> BINARY test_progs
> 16:15:41 bpf$ make -j14 test_progs
> make: 'test_progs' is up to date.
>
> Interestingly enough, this does not happen with your off-list version of
> the patch shared this morning, the one with order-only dependency for .d:
>
> +$(TRUNNER_TEST_OBJS): $(TRUNNER_OUTPUT)/%.test.o: $(TRUNNER_TESTS_DIR)/%.c | $(TRUNNER_OUTPUT)/%.test.d
>
> Could you please double-check what's going on?
After some investigation it turned out that behaviour is specific to LLVM.
Under certain not yet clear conditions clang writes .d file *after* writing .o file.
For example:
{llvm} 19:15:59 bpf$ rm ringbuf.test.o; make `pwd`/ringbuf.test.o; ls -l --time-style=full-iso `pwd`/ringbuf.test.{o,d}
TEST-OBJ [test_progs] ringbuf.test.o
-rw-rw-r-- 1 eddy eddy 1947 2024-07-11 19:16:01.059016929 -0700 /home/eddy/work/bpf-next/tools/testing/selftests/bpf/ringbuf.test.d
-rw-rw-r-- 1 eddy eddy 160544 2024-07-11 19:16:01.055016909 -0700 /home/eddy/work/bpf-next/tools/testing/selftests/bpf/ringbuf.test.o
Note that ringbuf.test.d is newer than ringbuf.test.o.
This happens on each 10 or 20 run of the command.
Such behaviour clearly defies the reason for dependency files generation.
The decision for now is to avoid specifying .d files as direct dependencies
of the .o files and use order-only dependencies instead.
The make feature for reloading included makefiles would take care
of correctly re-specifying dependencies.
[...]
