Orange Pi5 kernel

Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards

3 Commits   0 Branches   0 Tags
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   1) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   2) BPF Selftest Notes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   3) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   4) General instructions on running selftests can be found in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   5) `Documentation/bpf/bpf_devel_QA.rst`_.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   6) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   7) Additional information about selftest failures are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   8) documented here.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   9) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  10) profiler[23] test failures with clang/llvm <12.0.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  11) ==================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  12) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  13) With clang/llvm <12.0.0, the profiler[23] test may fail.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  14) The symptom looks like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  15) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  16) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  17) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  18)   // r9 is a pointer to map_value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  19)   // r7 is a scalar
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  20)   17:       bf 96 00 00 00 00 00 00 r6 = r9
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  21)   18:       0f 76 00 00 00 00 00 00 r6 += r7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  22)   math between map_value pointer and register with unbounded min value is not allowed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  23) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  24)   // the instructions below will not be seen in the verifier log
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  25)   19:       a5 07 01 00 01 01 00 00 if r7 < 257 goto +1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  26)   20:       bf 96 00 00 00 00 00 00 r6 = r9
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  27)   // r6 is used here
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  28) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  29) The verifier will reject such code with above error.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  30) At insn 18 the r7 is indeed unbounded. The later insn 19 checks the bounds and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  31) the insn 20 undoes map_value addition. It is currently impossible for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  32) verifier to understand such speculative pointer arithmetic.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  33) Hence
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  34)     https://reviews.llvm.org/D85570
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  35) addresses it on the compiler side. It was committed on llvm 12.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  36) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  37) The corresponding C code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  38) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  39) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  40)   for (int i = 0; i < MAX_CGROUPS_PATH_DEPTH; i++) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  41)           filepart_length = bpf_probe_read_str(payload, ...);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  42)           if (filepart_length <= MAX_PATH) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  43)                   barrier_var(filepart_length); // workaround
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  44)                   payload += filepart_length;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  45)           }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  46)   }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  47) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  48) bpf_iter test failures with clang/llvm 10.0.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  49) =============================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  50) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  51) With clang/llvm 10.0.0, the following two bpf_iter tests failed:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  52)   * ``bpf_iter/ipv6_route``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  53)   * ``bpf_iter/netlink``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  54) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  55) The symptom for ``bpf_iter/ipv6_route`` looks like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  56) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  57) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  58) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  59)   2: (79) r8 = *(u64 *)(r1 +8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  60)   ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  61)   14: (bf) r2 = r8
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  62)   15: (0f) r2 += r1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  63)   ; BPF_SEQ_PRINTF(seq, "%pi6 %02x ", &rt->fib6_dst.addr, rt->fib6_dst.plen);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  64)   16: (7b) *(u64 *)(r8 +64) = r2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  65)   only read is supported
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  66) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  67) The symptom for ``bpf_iter/netlink`` looks like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  68) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  69) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  70) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  71)   ; struct netlink_sock *nlk = ctx->sk;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  72)   2: (79) r7 = *(u64 *)(r1 +8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  73)   ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  74)   15: (bf) r2 = r7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  75)   16: (0f) r2 += r1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  76)   ; BPF_SEQ_PRINTF(seq, "%pK %-3d ", s, s->sk_protocol);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  77)   17: (7b) *(u64 *)(r7 +0) = r2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  78)   only read is supported
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  79) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  80) This is due to a llvm BPF backend bug. The fix 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  81)   https://reviews.llvm.org/D78466
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  82) has been pushed to llvm 10.x release branch and will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  83) available in 10.0.1. The fix is available in llvm 11.0.0 trunk.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  84) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  85) BPF CO-RE-based tests and Clang version
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  86) =======================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  87) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  88) A set of selftests use BPF target-specific built-ins, which might require
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  89) bleeding-edge Clang versions (Clang 12 nightly at this time).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  90) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  91) Few sub-tests of core_reloc test suit (part of test_progs test runner) require
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  92) the following built-ins, listed with corresponding Clang diffs introducing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  93) them to Clang/LLVM. These sub-tests are going to be skipped if Clang is too
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  94) old to support them, they shouldn't cause build failures or runtime test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  95) failures:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  96) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  97)   - __builtin_btf_type_id() ([0], [1], [2]);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  98)   - __builtin_preserve_type_info(), __builtin_preserve_enum_value() ([3], [4]).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  99) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)   [0] https://reviews.llvm.org/D74572
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)   [1] https://reviews.llvm.org/D74668
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)   [2] https://reviews.llvm.org/D85174
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)   [3] https://reviews.llvm.org/D83878
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)   [4] https://reviews.llvm.org/D83242