Re: [PATCH bpf-next v1 7/8] selftests/bpf: Add selftests for load-acquire and store-release instructions

["Ihor Solodrai" <ihor.solodrai@linux.dev>]

January 28, 2025 at 5:06 PM, "Eduard Zingerman" <eddyz87@gmail.com> wrote:



> 
> On Sat, 2025-01-25 at 02:19 +0000, Peilin Ye wrote:
> 
> > 
> > Add several ./test_progs tests:
> > 
> >  
> > 
> >  - atomics/load_acquire
> > 
> >  - atomics/store_release
> > 
> >  - arena_atomics/load_acquire
> > 
> >  - arena_atomics/store_release
> > 
> >  - verifier_load_acquire/*
> > 
> >  - verifier_store_release/*
> > 
> >  - verifier_precision/bpf_load_acquire
> > 
> >  - verifier_precision/bpf_store_release
> > 
> >  
> > 
> >  The last two tests are added to check if backtrack_insn() handles the
> > 
> >  new instructions correctly.
> > 
> >  
> > 
> >  Additionally, the last test also makes sure that the verifier
> > 
> >  "remembers" the value (in src_reg) we store-release into e.g. a stack
> > 
> >  slot. For example, if we take a look at the test program:
> > 
> >  
> > 
> >  #0: "r1 = 8;"
> > 
> >  #1: "store_release((u64 *)(r10 - 8), r1);"
> > 
> >  #2: "r1 = *(u64 *)(r10 - 8);"
> > 
> >  #3: "r2 = r10;"
> > 
> >  #4: "r2 += r1;" /* mark_precise */
> > 
> >  #5: "r0 = 0;"
> > 
> >  #6: "exit;"
> > 
> >  
> > 
> >  At #1, if the verifier doesn't remember that we wrote 8 to the stack,
> > 
> >  then later at #4 we would be adding an unbounded scalar value to the
> > 
> >  stack pointer, which would cause the program to be rejected:
> > 
> >  
> > 
> >  VERIFIER LOG:
> > 
> >  =============
> > 
> >  ...
> > 
> >  math between fp pointer and register with unbounded min value is not allowed
> > 
> >  
> > 
> >  All new tests depend on the pre-defined __BPF_FEATURE_LOAD_ACQ_STORE_REL
> > 
> >  feature macro, which implies -mcpu>=v4.
> > 
> 
> This restriction would mean that tests are skipped on BPF CI, as it
> 
> currently runs using llvm 17 and 18. Instead, I suggest using some

Eduard, if this feature requires a particular version of LLVM, it's
not difficult to add a configuration for it to BPF CI.

Whether we want to do it is an open question though. Issues may come
up with other tests when newer LLVM is used.

> 
> macro hiding an inline assembly as below:
> 
>  asm volatile (".8byte %[insn];"
> 
>  :
> 
>  : [insn]"i"(*(long *)&(BPF_RAW_INSN(...)))
> 
>  : /* correct clobbers here */);
> 
> See the usage of the __imm_insn() macro in the test suite.
> 
> Also, "BPF_ATOMIC loads from R%d %s is not allowed\n" and
> 
>  "BPF_ATOMIC stores into R%d %s is not allowed\n"
> 
> situations are not tested.
> 
> [...]
> 
> > 
> 
> [...]
>