Re: Failure in test_local_storage at bpf-next

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 10/6/20 6:23 PM, Andrii Nakryiko wrote:
On Tue, Oct 6, 2020 at 5:31 PM KP Singh <kpsingh@xxxxxxxxxxxx> wrote:

I noticed that test_local_storage is broken due to a BTF error at
bpf-next [67ed375530e2 ("samples: bpf: Driver interrupt statistics in
xdpsock")]

./test_progs -t test_local_storage
libbpf: prog 'socket_post_create': relo #0: parsing [28] struct socket + 0:0.1 2

This line is truncated, btw, please make sure you post the entire
output next time.

But, this seems like a bug in Clang, it produced invalid access index
string "0:0.1", there shouldn't be any other separator except ':' in
those strings.

Yonghong, can you please take a look? This seems to be a very recent
regression, I had to update to
6c7d713cf5d9bb188f1e73452a256386f0288bf7 sha from not-too-outdated
version to repro this.

Sorry. This indeed is a llvm regression. The guilty patch is
https://reviews.llvm.org/D88855 which adds NPM (new pass manager) support for BPF. The patch just merged this morning, thanks for catching the bug so fast. Since NPM is not used by default and the code refactoring looks okay, so I did not run selftests. But, yah, it does change some semantics of the code...

I just put a fix at https://reviews.llvm.org/D88942.
Hopefully to merge soon.


libbpf: prog 'socket_post_create': relo #0: failed to relocate: -22
libbpf: failed to perform CO-RE relocations: -22
libbpf: failed to load object 'local_storage'
libbpf: failed to load BPF skeleton 'local_storage': -22
test_test_local_storage:FAIL:skel_load lsm skeleton failed

by changing it to use vmlinux.h with:


[...]


clang --version
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
6c7d713cf5d9bb188f1e73452a256386f0288bf7)
Target: x86_64-unknown-linux-gnu
Thread model: posix

pahole --version
v1.18

This error goes away if I comment out the lsm/socket_post_create or
the lsm/socket_bind which makes me think that something in
bpf_core_apply_relo does not like two programs in the same object
having the same BTF type in its signature (but this just a guess, I
did not investigate more).  I was wondering if anyone has any ideas
what could be going on here.

PS: While working on task local storage, I noted that some of the
checks in this test were buggy and will send a patch to fix them as
well.

- KP



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux