| Message ID | 20240725114312.32197-1-daniel@iogearbox.net (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | f7578df913041f08b680aac2c660ebd71f35af3a |
| Headers | show |
| Series | pull-request: bpf 2024-07-25 | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Pull request for net |
| netdev/build_32bit | success | Errors and warnings before: 273 this patch: 273 |
| netdev/build_tools | success | Errors and warnings before: 12 this patch: 12 |
| netdev/build_clang | success | Errors and warnings before: 281 this patch: 281 |
| netdev/verify_signedoff | success | Signed-off-by tag matches author and committer |
| netdev/verify_fixes | success | Fixes tag looks correct |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 362 this patch: 362 |
| netdev/build_clang_rust | success | No Rust files in patch. Skipping build |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
On Thu, 25 Jul 2024 13:43:12 +0200 Daniel Borkmann wrote:
> Hi David, hi Jakub, hi Paolo, hi Eric,
While I have you, is this a known in BPF CI problem?
ar: libLLVM.so.19.0: cannot open shared object file: No such file or directory
Looks like our BPF CI builds are failing since 8pm PST yesterday.
On 7/25/24 3:30 PM, Jakub Kicinski wrote: > On Thu, 25 Jul 2024 13:43:12 +0200 Daniel Borkmann wrote: >> Hi David, hi Jakub, hi Paolo, hi Eric, > > While I have you, is this a known in BPF CI problem? > > ar: libLLVM.so.19.0: cannot open shared object file: No such file or directory > > Looks like our BPF CI builds are failing since 8pm PST yesterday. Looks like you may be one step ahead.. BPF CI runs tests with LLVM17 + LLVM18 at this point, so we haven't seen that issue yet. Maybe Manu has? Thanks, Daniel
On Thu, 25 Jul 2024 16:13:00 +0200 Daniel Borkmann wrote: > On 7/25/24 3:30 PM, Jakub Kicinski wrote: > > On Thu, 25 Jul 2024 13:43:12 +0200 Daniel Borkmann wrote: > >> Hi David, hi Jakub, hi Paolo, hi Eric, > > > > While I have you, is this a known in BPF CI problem? > > > > ar: libLLVM.so.19.0: cannot open shared object file: No such file or directory > > > > Looks like our BPF CI builds are failing since 8pm PST yesterday. > > Looks like you may be one step ahead.. BPF CI runs tests with LLVM17 + LLVM18 > at this point, so we haven't seen that issue yet. Maybe Manu has? FWIW we got a PR on the list last night which was based on fairly recent version of Linus's tree. I dropped it from the test queue, but I suspect once we FF this will come back.
Hello: This pull request was applied to netdev/net.git (main) by Jakub Kicinski <kuba@kernel.org>: On Thu, 25 Jul 2024 13:43:12 +0200 you wrote: > Hi David, hi Jakub, hi Paolo, hi Eric, > > The following pull-request contains BPF updates for your *net* tree. > > We've added 14 non-merge commits during the last 8 day(s) which contain > a total of 19 files changed, 177 insertions(+), 70 deletions(-). > > [...] Here is the summary with links: - pull-request: bpf 2024-07-25 https://git.kernel.org/netdev/net/c/f7578df91304 You are awesome, thank you!
> On Jul 25, 2024, at 7:16 AM, Jakub Kicinski <kuba@kernel.org> wrote: > > > > On Thu, 25 Jul 2024 16:13:00 +0200 Daniel Borkmann wrote: >> On 7/25/24 3:30 PM, Jakub Kicinski wrote: >>> On Thu, 25 Jul 2024 13:43:12 +0200 Daniel Borkmann wrote: >>>> Hi David, hi Jakub, hi Paolo, hi Eric, >>> >>> While I have you, is this a known in BPF CI problem? >>> >>> ar: libLLVM.so.19.0: cannot open shared object file: No such file or directory >>> >>> Looks like our BPF CI builds are failing since 8pm PST yesterday. >> >> Looks like you may be one step ahead.. BPF CI runs tests with LLVM17 + LLVM18 >> at this point, so we haven't seen that issue yet. Maybe Manu has? I did not play with llvm19 yet. Checking the BPF CI netdev builds that went red yesterday 8pm PST leads to https://github.com/kernel-patches/bpf/actions/runs/10087416772 BPF selftests build is failing with: CC bench_local_storage_create.o 3298 CC bench_htab_mem.o 3299 CC bench_bpf_crypto.o 3300 BINARY xskxceiver 3301 <command-line>: error: "_GNU_SOURCE" redefined [-Werror] 3302 <command-line>: note: this is the location of the previous definition 3303 BINARY xdp_hw_metadata 3304 BINARY xdp_features 3305 TEST-OBJ [test_maps] htab_map_batch_ops.test.o 3306 TEST-OBJ [test_maps] lpm_trie_map_batch_ops.test.o 3307 TEST-OBJ [test_maps] sk_storage_map.test.o 3308 TEST-OBJ [test_maps] map_percpu_stats.test.o across all combos or architectures/compilers. I did not see anything related to LLVM19 though. last failing build was today 5:17 am PST https://github.com/kernel-patches/bpf/actions/runs/10093925751 with the same symptoms. First successful at 8:02am: https://github.com/kernel-patches/bpf/actions/runs/10096557745 Manu > > FWIW we got a PR on the list last night which was based on fairly > recent version of Linus's tree. I dropped it from the test queue, > but I suspect once we FF this will come back.
On Thu, 25 Jul 2024 18:30:22 +0000 Manu Bretelle wrote: > I did not play with llvm19 yet. > > Checking the BPF CI netdev builds that went red yesterday 8pm PST leads to > https://github.com/kernel-patches/bpf/actions/runs/10087416772 > > BPF selftests build is failing with: > > CC bench_local_storage_create.o > 3298 CC bench_htab_mem.o > 3299 CC bench_bpf_crypto.o > 3300 BINARY xskxceiver > 3301 <command-line>: error: "_GNU_SOURCE" redefined [-Werror] > 3302 <command-line>: note: this is the location of the previous definition > 3303 BINARY xdp_hw_metadata > 3304 BINARY xdp_features > 3305 TEST-OBJ [test_maps] htab_map_batch_ops.test.o > 3306 TEST-OBJ [test_maps] lpm_trie_map_batch_ops.test.o > 3307 TEST-OBJ [test_maps] sk_storage_map.test.o > 3308 TEST-OBJ [test_maps] map_percpu_stats.test.o > > across all combos or architectures/compilers. I did not see anything related to LLVM19 though. > > last failing build was today 5:17 am PST https://github.com/kernel-patches/bpf/actions/runs/10093925751 > with the same symptoms. > > First successful at 8:02am: https://github.com/kernel-patches/bpf/actions/runs/10096557745 Ugh, seems like the GitHub UI messes up Firefox's ability to search :( I see it now, and it makes sense. Linus ended up with cc937dad85aea which was supposed to never make it upstream. On the LLVM19 I see this in all outputs: ar: libLLVM.so.19.0: cannot open shared object file: No such file or directory But presumably that's harmless, then.
> On Jul 25, 2024, at 11:40 AM, Jakub Kicinski <kuba@kernel.org> wrote: > > > > On the LLVM19 I see this in all outputs: > ar: libLLVM.so.19.0: cannot open shared object file: No such file or directory > > But presumably that's harmless, then. Oh I see. It seems this is only affecting gcc builds. Seem that nm/ar are not affected: # ldd /usr/bin/ar /usr/bin/nm /usr/bin/ar: linux-vdso.so.1 (0x00007fffa7376000) libbfd-2.34-system.so => /lib/x86_64-linux-gnu/libbfd-2.34-system.so (0x00007f6e90609000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6e90417000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6e903fb000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6e903f5000) /lib64/ld-linux-x86-64.so.2 (0x00007f6e9076e000) /usr/bin/nm: linux-vdso.so.1 (0x00007ffd817ad000) libbfd-2.34-system.so => /lib/x86_64-linux-gnu/libbfd-2.34-system.so (0x00007f09dc4ab000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f09dc2b9000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f09dc29d000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f09dc297000) /lib64/ld-linux-x86-64.so.2 (0x00007f09dc60c000) but the “llvm” versions are: # ldd /usr/bin/llvm-ar /usr/bin/llvm-nm /usr/bin/llvm-ar: linux-vdso.so.1 (0x00007ffd675b2000) libLLVM.so.19.0 => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe0ba21d000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe0ba03b000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe0b9eec000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe0b9ed1000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe0b9cdf000) /lib64/ld-linux-x86-64.so.2 (0x00007fe0ba260000) /usr/bin/llvm-nm: linux-vdso.so.1 (0x00007ffecd6ea000) libLLVM.so.19.0 => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffadeb05000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffade923000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffade7d4000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffade7b9000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffade5c7000) /lib64/ld-linux-x86-64.so.2 (0x00007ffadeb5a000) Seems the llvm package rom llvm repo shadows the one from the repo, installing libllvm19 as a side effect but not updating the ld conf path . # dpkg -l | grep llvm ii libllvm19:amd64 1:19~++20240722052718+f2eb7c7344a5-1~exp1~20240722172839.1099 amd64 Modular compiler and toolchain technologies, runtime library ii llvm 1:19.0-58~exp2+0~20240303102334.17~1.gbp3b61b3 amd64 Low-Level Virtual Machine (LLVM) ii llvm-19 1:19~++20240722052718+f2eb7c7344a5-1~exp1~20240722172839.1099 amd64 Modular compiler and toolchain technologies ii llvm-19-dev 1:19~++20240722052718+f2eb7c7344a5-1~exp1~20240722172839.1099 amd64 Modular compiler and toolchain technologies, libraries and headers ii llvm-19-linker-tools 1:19~++20240722052718+f2eb7c7344a5-1~exp1~20240722172839.1099 amd64 Modular compiler and toolchain technologies - Plugins ii llvm-19-runtime 1:19~++20240722052718+f2eb7c7344a5-1~exp1~20240722172839.1099 amd64 Modular compiler and toolchain technologies, IR interpreter ii llvm-19-tools 1:19~++20240722052718+f2eb7c7344a5-1~exp1~20240722172839.1099 amd64 Modular compiler and toolchain technologies, tools ii llvm-runtime:amd64 1:19.0-58~exp2+0~20240303102334.17~1.gbp3b61b3 amd64 Low-Level Virtual Machine (LLVM), bytecode interpreter Seems everything works so far. Going to cross fingers that it holds. Manu
Hi David, hi Jakub, hi Paolo, hi Eric, The following pull-request contains BPF updates for your *net* tree. We've added 14 non-merge commits during the last 8 day(s) which contain a total of 19 files changed, 177 insertions(+), 70 deletions(-). The main changes are: 1) Fix af_unix to disable MSG_OOB handling for sockets in BPF sockmap and BPF sockhash. Also add test coverage for this case, from Michal Luczaj. 2) Fix a segmentation issue when downgrading gso_size in the BPF helper bpf_skb_adjust_room(), from Fred Li. 3) Fix a compiler warning in resolve_btfids due to a missing type cast, from Liwei Song. 4) Fix stack allocation for arm64 to align the stack pointer at a 16 byte boundary in the fexit_sleep BPF selftest, from Puranjay Mohan. 5) Fix a xsk regression to require a flag when actuating tx_metadata_len, from Stanislav Fomichev. 6) Fix function prototype BTF dumping in libbpf for prototypes that have no input arguments, from Andrii Nakryiko. 7) Fix stacktrace symbol resolution in perf script for BPF programs containing subprograms, from Hou Tao. Please consider pulling these changes from: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git tags/for-netdev Thanks a lot! Also thanks to reporters, reviewers and testers of commits in this pull-request: Christophe Leroy, Daniel Borkmann, Hari Bathini, Jakub Sitnicki, Jiri Olsa, Julian Schindel, Krister Johansen, Kuniyuki Iwashima, Maciej Fijalkowski, Masami Hiramatsu (Google), Quentin Monnet, Stanislav Fomichev, Tejun Heo, Willem de Bruijn, Yonghong Song ---------------------------------------------------------------- The following changes since commit 0e03c643dc9389e61fa484562dae58c8d6e96d63: eth: fbnic: fix s390 build. (2024-07-17 06:25:14 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git tags/for-netdev for you to fetch changes up to 9b9969c40b0d63a8fca434d4ea01c60a39699aa3: selftests/bpf: Add XDP_UMEM_TX_METADATA_LEN to XSK TX metadata test (2024-07-25 11:57:33 +0200) ---------------------------------------------------------------- bpf-for-netdev ---------------------------------------------------------------- Andrii Nakryiko (1): libbpf: Fix no-args func prototype BTF dumping syntax Donald Hunter (1): bpftool: Fix typo in usage help Fred Li (1): bpf: Fix a segment issue when downgrading gso_size Hou Tao (1): bpf, events: Use prog to emit ksymbol event for main program Liwei Song (1): tools/resolve_btfids: Fix comparison of distinct pointer types warning in resolve_btfids Michal Luczaj (4): af_unix: Disable MSG_OOB handling for sockets in sockmap/sockhash selftests/bpf: Support SOCK_STREAM in unix_inet_redir_to_connected() selftests/bpf: Parametrize AF_UNIX redir functions to accept send() flags selftests/bpf: Test sockmap redirect for AF_UNIX MSG_OOB Naveen N Rao (2): MAINTAINERS: Update email address of Naveen MAINTAINERS: Update powerpc BPF JIT maintainers Puranjay Mohan (1): selftests/bpf: fexit_sleep: Fix stack allocation for arm64 Stanislav Fomichev (2): xsk: Require XDP_UMEM_TX_METADATA_LEN to actuate tx_metadata_len selftests/bpf: Add XDP_UMEM_TX_METADATA_LEN to XSK TX metadata test .mailmap | 2 + Documentation/networking/xsk-tx-metadata.rst | 16 ++-- MAINTAINERS | 8 +- include/uapi/linux/if_xdp.h | 4 + kernel/events/core.c | 28 ++++--- net/core/filter.c | 15 +++- net/unix/af_unix.c | 41 ++++++++++- net/unix/unix_bpf.c | 3 + net/xdp/xdp_umem.c | 9 ++- tools/bpf/bpftool/prog.c | 2 +- tools/bpf/resolve_btfids/main.c | 2 +- tools/include/uapi/linux/if_xdp.h | 4 + tools/lib/bpf/btf_dump.c | 8 +- tools/testing/selftests/bpf/DENYLIST.aarch64 | 1 - .../testing/selftests/bpf/prog_tests/fexit_sleep.c | 8 +- .../selftests/bpf/prog_tests/sockmap_listen.c | 85 +++++++++++++++------- .../selftests/bpf/prog_tests/xdp_metadata.c | 3 +- .../bpf/progs/btf_dump_test_case_multidim.c | 4 +- .../bpf/progs/btf_dump_test_case_syntax.c | 4 +- 19 files changed, 177 insertions(+), 70 deletions(-)