* Error loading xdp program that worked with bpf_load
@ 2020-06-10 21:01 Elerion
2020-06-10 21:06 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 12+ messages in thread
From: Elerion @ 2020-06-10 21:01 UTC (permalink / raw)
To: xdp-newbies
I used this to load my xdp program
https://github.com/torvalds/linux/blob/master/samples/bpf/bpf_load.c
but it doesn't seem to work on new style maps so I am using libbpf
bpf_object__open now.
But now it shows this
libbpf: Error loading BTF: Invalid argument(22)
libbpf: magic: 0xeb9f
version: 1
flags: 0x0
hdr_len: 24
type_off: 0
type_len: 2088
str_off: 2088
str_len: 11234
btf_total_size: 13346
[1] STRUCT (anon) size=32 vlen=4
type type_id=2 bits_offset=0
max_entries type_id=6 bits_offset=64
key type_id=8 bits_offset=128
value type_id=12 bits_offset=192
[2] PTR (anon) type_id=4
[3] INT int size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
more type information....
libbpf: Error loading .BTF into kernel: -22.
How do I fix this?
5.3.0-53-generic #47~18.04.1-Ubuntu SMP Thu May 7 13:10:50 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux
Ubuntu clang version
10.0.1-++20200529024103+a634a80615b-1~exp1~20200529124721.169
Target: x86_64-pc-linux-gnu
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Error loading xdp program that worked with bpf_load 2020-06-10 21:01 Error loading xdp program that worked with bpf_load Elerion @ 2020-06-10 21:06 ` Toke Høiland-Jørgensen 2020-06-10 21:08 ` Elerion 0 siblings, 1 reply; 12+ messages in thread From: Toke Høiland-Jørgensen @ 2020-06-10 21:06 UTC (permalink / raw) To: Elerion, xdp-newbies Elerion <elerion1000@gmail.com> writes: > I used this to load my xdp program > https://github.com/torvalds/linux/blob/master/samples/bpf/bpf_load.c > but it doesn't seem to work on new style maps so I am using libbpf > bpf_object__open now. > > But now it shows this > > libbpf: Error loading BTF: Invalid argument(22) > libbpf: magic: 0xeb9f > version: 1 > flags: 0x0 > hdr_len: 24 > type_off: 0 > type_len: 2088 > str_off: 2088 > str_len: 11234 > btf_total_size: 13346 > [1] STRUCT (anon) size=32 vlen=4 > type type_id=2 bits_offset=0 > max_entries type_id=6 bits_offset=64 > key type_id=8 bits_offset=128 > value type_id=12 bits_offset=192 > [2] PTR (anon) type_id=4 > [3] INT int size=4 bits_offset=0 nr_bits=32 encoding=SIGNED > more type information.... > libbpf: Error loading .BTF into kernel: -22. > > How do I fix this? Usually the last line of type information (which it looks like you snipped above?) contains the error, although sometimes it can be hard to spot because it looks like part of the type... -Toke ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Error loading xdp program that worked with bpf_load 2020-06-10 21:06 ` Toke Høiland-Jørgensen @ 2020-06-10 21:08 ` Elerion 2020-06-10 21:37 ` Toke Høiland-Jørgensen 0 siblings, 1 reply; 12+ messages in thread From: Elerion @ 2020-06-10 21:08 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: xdp-newbies Here is the full dump. bpf_object__open libbpf: Error loading BTF: Invalid argument(22) libbpf: magic: 0xeb9f version: 1 flags: 0x0 hdr_len: 24 type_off: 0 type_len: 2088 str_off: 2088 str_len: 11234 btf_total_size: 13346 [1] STRUCT (anon) size=32 vlen=4 type type_id=2 bits_offset=0 max_entries type_id=6 bits_offset=64 key type_id=8 bits_offset=128 value type_id=12 bits_offset=192 [2] PTR (anon) type_id=4 [3] INT int size=4 bits_offset=0 nr_bits=32 encoding=SIGNED [4] ARRAY (anon) type_id=3 index_type_id=5 nr_elems=2 [5] INT __ARRAY_SIZE_TYPE__ size=4 bits_offset=0 nr_bits=32 encoding=(none) [6] PTR (anon) type_id=7 [7] ARRAY (anon) type_id=3 index_type_id=5 nr_elems=1 [8] PTR (anon) type_id=9 [9] TYPEDEF uint32_t type_id=10 [10] TYPEDEF __uint32_t type_id=11 [11] INT unsigned int size=4 bits_offset=0 nr_bits=32 encoding=(none) [12] PTR (anon) type_id=13 [13] STRUCT config size=48 vlen=6 lock type_id=14 bits_offset=0 new_conn_limit type_id=16 bits_offset=64 rate_limit type_id=16 bits_offset=128 main_ip type_id=18 bits_offset=192 new_ip_count type_id=16 bits_offset=256 new_ip_timestamp type_id=16 bits_offset=320 [14] STRUCT bpf_spin_lock size=4 vlen=1 val type_id=15 bits_offset=0 [15] TYPEDEF __u32 type_id=11 [16] TYPEDEF uint_fast64_t type_id=17 [17] INT long long unsigned int size=8 bits_offset=0 nr_bits=64 encoding=(none) [18] TYPEDEF uint_fast32_t type_id=11 [19] VAR config_map type_id=1 linkage=1 [20] STRUCT (anon) size=32 vlen=4 type type_id=21 bits_offset=0 max_entries type_id=6 bits_offset=64 key type_id=8 bits_offset=128 value type_id=23 bits_offset=192 [21] PTR (anon) type_id=22 value type_id=8 bits_offset=192 [49] PTR (anon) type_id=50 [50] ARRAY (anon) type_id=3 index_type_id=5 nr_elems=17 [51] PTR (anon) type_id=52 [52] ARRAY (anon) type_id=3 index_type_id=5 nr_elems=128 [53] VAR xsk_map type_id=48 linkage=1 [54] STRUCT (anon) size=32 vlen=4 type type_id=6 bits_offset=0 max_entries type_id=27 bits_offset=64 key type_id=8 bits_offset=128 value type_id=55 bits_offset=192 [55] PTR (anon) type_id=56 [56] STRUCT server_rate_limit_entry size=72 vlen=9 under_attack_start type_id=16 bits_offset=0 under_attack_last type_id=16 bits_offset=64 packets_sent type_id=16 bits_offset=128 packets_sent_time type_id=16 bits_offset=192 tcp_packets type_id=16 bits_offset=256 misc_packets type_id=16 bits_offset=320 a2s_packets type_id=16 bits_offset=384 a2sinfo_packets type_id=16 bits_offset=448 syn_packets type_id=16 bits_offset=512 [57] VAR server_rate_limits type_id=54 linkage=1 [58] STRUCT (anon) size=32 vlen=4 type type_id=59 bits_offset=0 max_entries type_id=61 bits_offset=64 key type_id=8 bits_offset=128 value type_id=63 bits_offset=192 [59] PTR (anon) type_id=60 [60] ARRAY (anon) type_id=3 index_type_id=5 nr_elems=9 [61] PTR (anon) type_id=62 [62] ARRAY (anon) type_id=3 index_type_id=5 nr_elems=65536 [63] PTR (anon) type_id=64 [64] STRUCT ip_addr_history size=24 vlen=3 timestamp type_id=16 bits_offset=0 hits type_id=16 bits_offset=64 created type_id=16 bits_offset=128 [65] VAR client_rate_limits type_id=58 linkage=1 [66] PTR (anon) type_id=67 [67] STRUCT xdp_md size=20 vlen=5 data type_id=15 bits_offset=0 data_end type_id=15 bits_offset=32 data_meta type_id=15 bits_offset=64 ingress_ifindex type_id=15 bits_offset=96 rx_queue_index type_id=15 bits_offset=128 [68] FUNC_PROTO (anon) return=3 args=(66 ctx) [69] FUNC xdp_program type_id=68 vlen != 0 libbpf: Error loading .BTF into kernel: -22. bpf_object__find_program_by_title Segmentation fault (core dumped) On Wed, Jun 10, 2020 at 2:06 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Elerion <elerion1000@gmail.com> writes: > > > I used this to load my xdp program > > https://github.com/torvalds/linux/blob/master/samples/bpf/bpf_load.c > > but it doesn't seem to work on new style maps so I am using libbpf > > bpf_object__open now. > > > > But now it shows this > > > > libbpf: Error loading BTF: Invalid argument(22) > > libbpf: magic: 0xeb9f > > version: 1 > > flags: 0x0 > > hdr_len: 24 > > type_off: 0 > > type_len: 2088 > > str_off: 2088 > > str_len: 11234 > > btf_total_size: 13346 > > [1] STRUCT (anon) size=32 vlen=4 > > type type_id=2 bits_offset=0 > > max_entries type_id=6 bits_offset=64 > > key type_id=8 bits_offset=128 > > value type_id=12 bits_offset=192 > > [2] PTR (anon) type_id=4 > > [3] INT int size=4 bits_offset=0 nr_bits=32 encoding=SIGNED > > more type information.... > > libbpf: Error loading .BTF into kernel: -22. > > > > How do I fix this? > > Usually the last line of type information (which it looks like you > snipped above?) contains the error, although sometimes it can be hard to > spot because it looks like part of the type... > > -Toke > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Error loading xdp program that worked with bpf_load 2020-06-10 21:08 ` Elerion @ 2020-06-10 21:37 ` Toke Høiland-Jørgensen 2020-06-10 21:44 ` Elerion 2020-06-10 21:50 ` Elerion 0 siblings, 2 replies; 12+ messages in thread From: Toke Høiland-Jørgensen @ 2020-06-10 21:37 UTC (permalink / raw) To: Elerion; +Cc: xdp-newbies Elerion <elerion1000@gmail.com> writes: > [69] FUNC xdp_program type_id=68 vlen != 0 'vlen != 0' is the error. Not sure why you hit that; what's the output of 'bpftool btf dump file yourprog.o' ? -Toke ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Error loading xdp program that worked with bpf_load 2020-06-10 21:37 ` Toke Høiland-Jørgensen @ 2020-06-10 21:44 ` Elerion 2020-06-10 21:50 ` Elerion 1 sibling, 0 replies; 12+ messages in thread From: Elerion @ 2020-06-10 21:44 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: xdp-newbies [1] STRUCT '(anon)' size=32 vlen=4 'type' type_id=2 bits_offset=0 'max_entries' type_id=6 bits_offset=64 'key' type_id=8 bits_offset=128 'value' type_id=12 bits_offset=192 [2] PTR '(anon)' type_id=4 [3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED [4] ARRAY '(anon)' type_id=3 index_type_id=5 nr_elems=2 [5] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none) [6] PTR '(anon)' type_id=7 [7] ARRAY '(anon)' type_id=3 index_type_id=5 nr_elems=1 [8] PTR '(anon)' type_id=9 [9] TYPEDEF 'uint32_t' type_id=10 [10] TYPEDEF '__uint32_t' type_id=11 [11] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none) [12] PTR '(anon)' type_id=13 [13] STRUCT 'config' size=48 vlen=6 'lock' type_id=14 bits_offset=0 'new_conn_limit' type_id=16 bits_offset=64 'rate_limit' type_id=16 bits_offset=128 'main_ip' type_id=18 bits_offset=192 'new_ip_count' type_id=16 bits_offset=256 'new_ip_timestamp' type_id=16 bits_offset=320 [14] STRUCT 'bpf_spin_lock' size=4 vlen=1 'val' type_id=15 bits_offset=0 [15] TYPEDEF '__u32' type_id=11 [16] TYPEDEF 'uint_fast64_t' type_id=17 [17] INT 'long long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none) [18] TYPEDEF 'uint_fast32_t' type_id=11 [19] VAR 'config_map' type_id=1, linkage=global-alloc [20] STRUCT '(anon)' size=32 vlen=4 'type' type_id=21 bits_offset=0 'max_entries' type_id=6 bits_offset=64 'key' type_id=8 bits_offset=128 'value' type_id=23 bits_offset=192 [21] PTR '(anon)' type_id=22 [22] ARRAY '(anon)' type_id=3 index_type_id=5 nr_elems=6 [23] PTR '(anon)' type_id=24 [24] STRUCT 'global_stats' size=40 vlen=5 'packet_in' type_id=16 bits_offset=0 'packet_out' type_id=16 bits_offset=64 'bytes_in' type_id=16 bits_offset=128 'bytes_out' type_id=16 bits_offset=192 'packets_dropped' type_id=16 bits_offset=256 [25] VAR 'stats_map' type_id=20, linkage=global-alloc [26] STRUCT '(anon)' size=32 vlen=4 'type' type_id=6 bits_offset=0 'max_entries' type_id=27 bits_offset=64 'key' type_id=29 bits_offset=128 'value' type_id=32 bits_offset=192 [27] PTR '(anon)' type_id=28 [28] ARRAY '(anon)' type_id=3 index_type_id=5 nr_elems=512 [29] PTR '(anon)' type_id=30 [30] TYPEDEF 'uint64_t' type_id=31 [31] TYPEDEF '__uint64_t' type_id=17 [32] PTR '(anon)' type_id=33 [33] STRUCT 'forwarding_rule' size=40 vlen=9 'bind_addr' type_id=9 bits_offset=0 'bind_port' type_id=34 bits_offset=32 'to_addr' type_id=9 bits_offset=64 'to_port' type_id=34 bits_offset=96 'steam_port' type_id=34 bits_offset=112 'inner_addr' type_id=9 bits_offset=128 'a2s_info_cache' type_id=18 bits_offset=160 'cache_time' type_id=16 bits_offset=192 'tcp_port1' type_id=34 bits_offset=256 [34] TYPEDEF 'uint16_t' type_id=35 [35] TYPEDEF '__uint16_t' type_id=36 [36] INT 'unsigned short' size=2 bits_offset=0 nr_bits=16 encoding=(none) [37] VAR 'tunnel_map' type_id=26, linkage=global-alloc [38] STRUCT '(anon)' size=32 vlen=4 'type' type_id=2 bits_offset=0 'max_entries' type_id=27 bits_offset=64 'key' type_id=8 bits_offset=128 'value' type_id=32 bits_offset=192 [39] VAR 'forwarding_map' type_id=38, linkage=global-alloc [40] STRUCT '(anon)' size=32 vlen=4 'type' type_id=6 bits_offset=0 'max_entries' type_id=27 bits_offset=64 'key' type_id=8 bits_offset=128 'value' type_id=41 bits_offset=192 [41] PTR '(anon)' type_id=42 [42] STRUCT 'a2s_info_cache_entry' size=40 vlen=6 'age' type_id=30 bits_offset=0 'misses' type_id=30 bits_offset=64 'hits' type_id=30 bits_offset=128 'udp_data' type_id=43 bits_offset=192 'len' type_id=34 bits_offset=256 'csum' type_id=9 bits_offset=288 [43] PTR '(anon)' type_id=44 [44] TYPEDEF 'uint8_t' type_id=45 [45] TYPEDEF '__uint8_t' type_id=46 [46] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=(none) [47] VAR 'a2s_info_cache_map' type_id=40, linkage=global-alloc [48] STRUCT '(anon)' size=32 vlen=4 'type' type_id=49 bits_offset=0 'key' type_id=8 bits_offset=128 'value' type_id=8 bits_offset=192 [49] PTR '(anon)' type_id=50 [50] ARRAY '(anon)' type_id=3 index_type_id=5 nr_elems=17 [51] PTR '(anon)' type_id=52 [52] ARRAY '(anon)' type_id=3 index_type_id=5 nr_elems=128 [53] VAR 'xsk_map' type_id=48, linkage=global-alloc [54] STRUCT '(anon)' size=32 vlen=4 'type' type_id=6 bits_offset=0 'max_entries' type_id=27 bits_offset=64 'key' type_id=8 bits_offset=128 'value' type_id=55 bits_offset=192 [55] PTR '(anon)' type_id=56 [56] STRUCT 'server_rate_limit_entry' size=72 vlen=9 'under_attack_start' type_id=16 bits_offset=0 'under_attack_last' type_id=16 bits_offset=64 'packets_sent' type_id=16 bits_offset=128 'packets_sent_time' type_id=16 bits_offset=192 'tcp_packets' type_id=16 bits_offset=256 'misc_packets' type_id=16 bits_offset=320 'a2s_packets' type_id=16 bits_offset=384 'a2sinfo_packets' type_id=16 bits_offset=448 'syn_packets' type_id=16 bits_offset=512 [57] VAR 'server_rate_limits' type_id=54, linkage=global-alloc [58] STRUCT '(anon)' size=32 vlen=4 'type' type_id=59 bits_offset=0 'max_entries' type_id=61 bits_offset=64 'key' type_id=8 bits_offset=128 'value' type_id=63 bits_offset=192 [59] PTR '(anon)' type_id=60 [60] ARRAY '(anon)' type_id=3 index_type_id=5 nr_elems=9 [61] PTR '(anon)' type_id=62 [62] ARRAY '(anon)' type_id=3 index_type_id=5 nr_elems=65536 [63] PTR '(anon)' type_id=64 [64] STRUCT 'ip_addr_history' size=24 vlen=3 'timestamp' type_id=16 bits_offset=0 'hits' type_id=16 bits_offset=64 'created' type_id=16 bits_offset=128 [65] VAR 'client_rate_limits' type_id=58, linkage=global-alloc [66] PTR '(anon)' type_id=67 [67] STRUCT 'xdp_md' size=20 vlen=5 'data' type_id=15 bits_offset=0 'data_end' type_id=15 bits_offset=32 'data_meta' type_id=15 bits_offset=64 'ingress_ifindex' type_id=15 bits_offset=96 'rx_queue_index' type_id=15 bits_offset=128 [68] FUNC_PROTO '(anon)' ret_type_id=3 vlen=1 'ctx' type_id=66 [69] FUNC 'xdp_program' type_id=68 [70] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED [71] ARRAY '(anon)' type_id=70 index_type_id=5 nr_elems=4 [72] VAR '_license' type_id=71, linkage=global-alloc [73] DATASEC '.maps' size=0 vlen=8 type_id=19 offset=0 size=32 type_id=25 offset=0 size=32 type_id=37 offset=0 size=32 type_id=39 offset=0 size=32 type_id=47 offset=0 size=32 type_id=53 offset=0 size=32 type_id=57 offset=0 size=32 type_id=65 offset=0 size=32 [74] DATASEC 'license' size=0 vlen=1 type_id=72 offset=0 size=4 On Wed, Jun 10, 2020 at 2:38 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Elerion <elerion1000@gmail.com> writes: > > > [69] FUNC xdp_program type_id=68 vlen != 0 > > 'vlen != 0' is the error. Not sure why you hit that; what's the output > of 'bpftool btf dump file yourprog.o' ? > > -Toke > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Error loading xdp program that worked with bpf_load 2020-06-10 21:37 ` Toke Høiland-Jørgensen 2020-06-10 21:44 ` Elerion @ 2020-06-10 21:50 ` Elerion 2020-06-11 10:59 ` Jesper Dangaard Brouer 1 sibling, 1 reply; 12+ messages in thread From: Elerion @ 2020-06-10 21:50 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: xdp-newbies Never mind, I fixed it by downgrading to Clang 9. It appears to be an issue with Clang/LLVM 10+ https://github.com/cilium/ebpf/issues/43 On Wed, Jun 10, 2020 at 2:38 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Elerion <elerion1000@gmail.com> writes: > > > [69] FUNC xdp_program type_id=68 vlen != 0 > > 'vlen != 0' is the error. Not sure why you hit that; what's the output > of 'bpftool btf dump file yourprog.o' ? > > -Toke > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Error loading xdp program that worked with bpf_load 2020-06-10 21:50 ` Elerion @ 2020-06-11 10:59 ` Jesper Dangaard Brouer 2020-06-11 16:34 ` Andrii Nakryiko 0 siblings, 1 reply; 12+ messages in thread From: Jesper Dangaard Brouer @ 2020-06-11 10:59 UTC (permalink / raw) To: Elerion, iovisor-dev Cc: brouer, Toke Høiland-Jørgensen, xdp-newbies, Andrii Nakryiko, Yonghong Song (Cross-posting to iovisor-dev) Seeking input from BPF-llvm developers. How come Clang/LLVM 10+ is generating incompatible BTF-info in ELF file, and downgrading to LLVM-9 fixes the issue ? On Wed, 10 Jun 2020 14:50:27 -0700 Elerion <elerion1000@gmail.com> wrote: > Never mind, I fixed it by downgrading to Clang 9. > > It appears to be an issue with Clang/LLVM 10+ > > https://github.com/cilium/ebpf/issues/43 > > On Wed, Jun 10, 2020 at 2:38 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > > > Elerion <elerion1000@gmail.com> writes: > > > > > [69] FUNC xdp_program type_id=68 vlen != 0 > > > > 'vlen != 0' is the error. Not sure why you hit that; what's the output > > of 'bpftool btf dump file yourprog.o' ? > > > > -Toke > > -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Error loading xdp program that worked with bpf_load 2020-06-11 10:59 ` Jesper Dangaard Brouer @ 2020-06-11 16:34 ` Andrii Nakryiko 2020-06-11 16:39 ` [iovisor-dev] " Alexei Starovoitov 2020-06-11 20:40 ` Elerion 0 siblings, 2 replies; 12+ messages in thread From: Andrii Nakryiko @ 2020-06-11 16:34 UTC (permalink / raw) To: Jesper Dangaard Brouer Cc: Elerion, iovisor-dev, Toke Høiland-Jørgensen, Xdp, Yonghong Song On Thu, Jun 11, 2020 at 4:00 AM Jesper Dangaard Brouer <brouer@redhat.com> wrote: > > (Cross-posting to iovisor-dev) > > Seeking input from BPF-llvm developers. How come Clang/LLVM 10+ is > generating incompatible BTF-info in ELF file, and downgrading to LLVM-9 > fixes the issue ? > > > On Wed, 10 Jun 2020 14:50:27 -0700 Elerion <elerion1000@gmail.com> wrote: > > > Never mind, I fixed it by downgrading to Clang 9. > > > > It appears to be an issue with Clang/LLVM 10+ > > > > https://github.com/cilium/ebpf/issues/43 This is newer Clang recording that function is global, not static. libbpf is sanitizing BTF to remove this flag, if kernel doesn't support this. But given this is re-implementation of libbpf, that's probably not happening, right? > > > > On Wed, Jun 10, 2020 at 2:38 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > > > > > Elerion <elerion1000@gmail.com> writes: > > > > > > > [69] FUNC xdp_program type_id=68 vlen != 0 > > > > > > 'vlen != 0' is the error. Not sure why you hit that; what's the output > > > of 'bpftool btf dump file yourprog.o' ? > > > > > > -Toke > > > > > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > LinkedIn: http://www.linkedin.com/in/brouer > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [iovisor-dev] Error loading xdp program that worked with bpf_load 2020-06-11 16:34 ` Andrii Nakryiko @ 2020-06-11 16:39 ` Alexei Starovoitov 2020-06-11 20:40 ` Elerion 1 sibling, 0 replies; 12+ messages in thread From: Alexei Starovoitov @ 2020-06-11 16:39 UTC (permalink / raw) To: Andrii Nakryiko Cc: Jesper Dangaard Brouer, Elerion, iovisor-dev, Toke Høiland-Jørgensen, Xdp, Yonghong Song, bpf On Thu, Jun 11, 2020 at 9:35 AM Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > On Thu, Jun 11, 2020 at 4:00 AM Jesper Dangaard Brouer > <brouer@redhat.com> wrote: > > > > (Cross-posting to iovisor-dev) > > > > Seeking input from BPF-llvm developers. How come Clang/LLVM 10+ is > > generating incompatible BTF-info in ELF file, and downgrading to LLVM-9 > > fixes the issue ? > > > > > > On Wed, 10 Jun 2020 14:50:27 -0700 Elerion <elerion1000@gmail.com> wrote: > > > > > Never mind, I fixed it by downgrading to Clang 9. > > > > > > It appears to be an issue with Clang/LLVM 10+ > > > > > > https://github.com/cilium/ebpf/issues/43 > > This is newer Clang recording that function is global, not static. > libbpf is sanitizing BTF to remove this flag, if kernel doesn't > support this. But given this is re-implementation of libbpf, that's > probably not happening, right? just running ./test_xdp_veth.sh on the latest bpf-next with the latest clang I see: BTF debug data section '.BTF' rejected: Invalid argument (22)! - Length: 514 Verifier analysis: ... [11] VAR _license type_id=9 linkage=1 [12] DATASEC license size=0 vlen=1 size == 0 BTF debug data section '.BTF' rejected: Invalid argument (22)! - Length: 494 Verifier analysis: ... [11] VAR _license type_id=9 linkage=1 [12] DATASEC license size=0 vlen=1 size == 0 BTF debug data section '.BTF' rejected: Invalid argument (22)! 11] VAR _license type_id=9 linkage=1 [12] DATASEC license size=0 vlen=1 size == 0 PING 10.1.1.33 (10.1.1.33) 56(84) bytes of data. 64 bytes from 10.1.1.33: icmp_seq=1 ttl=64 time=0.042 ms --- 10.1.1.33 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.042/0.042/0.042/0.000 ms selftests: xdp_veth [PASS] Is that just the noise from libbpf probing or what? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Error loading xdp program that worked with bpf_load 2020-06-11 16:34 ` Andrii Nakryiko 2020-06-11 16:39 ` [iovisor-dev] " Alexei Starovoitov @ 2020-06-11 20:40 ` Elerion 2020-06-11 20:46 ` Andrii Nakryiko 1 sibling, 1 reply; 12+ messages in thread From: Elerion @ 2020-06-11 20:40 UTC (permalink / raw) To: Andrii Nakryiko Cc: Jesper Dangaard Brouer, iovisor-dev, Toke Høiland-Jørgensen, Xdp, Yonghong Song I am using libbpf from here https://github.com/libbpf/libbpf I'm not using ebpf. I just linked to the ebpf issue because it seems like the only thing related to this problem when I googled it. On Thu, Jun 11, 2020 at 9:34 AM Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > On Thu, Jun 11, 2020 at 4:00 AM Jesper Dangaard Brouer > <brouer@redhat.com> wrote: > > > > (Cross-posting to iovisor-dev) > > > > Seeking input from BPF-llvm developers. How come Clang/LLVM 10+ is > > generating incompatible BTF-info in ELF file, and downgrading to LLVM-9 > > fixes the issue ? > > > > > > On Wed, 10 Jun 2020 14:50:27 -0700 Elerion <elerion1000@gmail.com> wrote: > > > > > Never mind, I fixed it by downgrading to Clang 9. > > > > > > It appears to be an issue with Clang/LLVM 10+ > > > > > > https://github.com/cilium/ebpf/issues/43 > > This is newer Clang recording that function is global, not static. > libbpf is sanitizing BTF to remove this flag, if kernel doesn't > support this. But given this is re-implementation of libbpf, that's > probably not happening, right? > > > > > > > On Wed, Jun 10, 2020 at 2:38 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > > > > > > > Elerion <elerion1000@gmail.com> writes: > > > > > > > > > [69] FUNC xdp_program type_id=68 vlen != 0 > > > > > > > > 'vlen != 0' is the error. Not sure why you hit that; what's the output > > > > of 'bpftool btf dump file yourprog.o' ? > > > > > > > > -Toke > > > > > > > > > > -- > > Best regards, > > Jesper Dangaard Brouer > > MSc.CS, Principal Kernel Engineer at Red Hat > > LinkedIn: http://www.linkedin.com/in/brouer > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Error loading xdp program that worked with bpf_load 2020-06-11 20:40 ` Elerion @ 2020-06-11 20:46 ` Andrii Nakryiko 2020-06-11 21:11 ` Elerion 0 siblings, 1 reply; 12+ messages in thread From: Andrii Nakryiko @ 2020-06-11 20:46 UTC (permalink / raw) To: Elerion Cc: Jesper Dangaard Brouer, iovisor-dev, Toke Høiland-Jørgensen, Xdp, Yonghong Song On Thu, Jun 11, 2020 at 1:41 PM Elerion <elerion1000@gmail.com> wrote: > > I am using libbpf from here https://github.com/libbpf/libbpf I'm not > using ebpf. I just linked to the ebpf issue because it seems like the > only thing related to this problem when I googled it. Ok, that I can help with, then. What's the kernel version? Where I can find repro? Steps, etc. Basically, a bit more context would help, as I wasn't part of initial discussion. > > On Thu, Jun 11, 2020 at 9:34 AM Andrii Nakryiko > <andrii.nakryiko@gmail.com> wrote: > > > > On Thu, Jun 11, 2020 at 4:00 AM Jesper Dangaard Brouer > > <brouer@redhat.com> wrote: > > > > > > (Cross-posting to iovisor-dev) > > > > > > Seeking input from BPF-llvm developers. How come Clang/LLVM 10+ is > > > generating incompatible BTF-info in ELF file, and downgrading to LLVM-9 > > > fixes the issue ? > > > > > > > > > On Wed, 10 Jun 2020 14:50:27 -0700 Elerion <elerion1000@gmail.com> wrote: > > > > > > > Never mind, I fixed it by downgrading to Clang 9. > > > > > > > > It appears to be an issue with Clang/LLVM 10+ > > > > > > > > https://github.com/cilium/ebpf/issues/43 > > > > This is newer Clang recording that function is global, not static. > > libbpf is sanitizing BTF to remove this flag, if kernel doesn't > > support this. But given this is re-implementation of libbpf, that's > > probably not happening, right? > > > > > > > > > > On Wed, Jun 10, 2020 at 2:38 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > > > > > > > > > Elerion <elerion1000@gmail.com> writes: > > > > > > > > > > > [69] FUNC xdp_program type_id=68 vlen != 0 > > > > > > > > > > 'vlen != 0' is the error. Not sure why you hit that; what's the output > > > > > of 'bpftool btf dump file yourprog.o' ? > > > > > > > > > > -Toke > > > > > > > > > > > > > > -- > > > Best regards, > > > Jesper Dangaard Brouer > > > MSc.CS, Principal Kernel Engineer at Red Hat > > > LinkedIn: http://www.linkedin.com/in/brouer > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Error loading xdp program that worked with bpf_load 2020-06-11 20:46 ` Andrii Nakryiko @ 2020-06-11 21:11 ` Elerion 0 siblings, 0 replies; 12+ messages in thread From: Elerion @ 2020-06-11 21:11 UTC (permalink / raw) To: Andrii Nakryiko Cc: Jesper Dangaard Brouer, iovisor-dev, Toke Høiland-Jørgensen, Xdp, Yonghong Song Hello here's some of the basic information, I don't have a minimum code sample to reproduce the error and I don't really feel inclined to spend the time to make one since I have already found a solution. I'm not able to release the production code we are using. 5.3.0-53-generic #47~18.04.1-Ubuntu SMP Thu May 7 13:10:50 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Ubuntu clang version 10.0.1-++20200529024103+a634a80615b-1~exp1~20200529124721.169 Target: x86_64-pc-linux-gnu You can find the discussion here: https://www.spinics.net/lists/xdp-newbies/msg01730.html On Thu, Jun 11, 2020 at 1:46 PM Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > On Thu, Jun 11, 2020 at 1:41 PM Elerion <elerion1000@gmail.com> wrote: > > > > I am using libbpf from here https://github.com/libbpf/libbpf I'm not > > using ebpf. I just linked to the ebpf issue because it seems like the > > only thing related to this problem when I googled it. > > Ok, that I can help with, then. > > What's the kernel version? Where I can find repro? Steps, etc. > Basically, a bit more context would help, as I wasn't part of initial > discussion. > > > > > > On Thu, Jun 11, 2020 at 9:34 AM Andrii Nakryiko > > <andrii.nakryiko@gmail.com> wrote: > > > > > > On Thu, Jun 11, 2020 at 4:00 AM Jesper Dangaard Brouer > > > <brouer@redhat.com> wrote: > > > > > > > > (Cross-posting to iovisor-dev) > > > > > > > > Seeking input from BPF-llvm developers. How come Clang/LLVM 10+ is > > > > generating incompatible BTF-info in ELF file, and downgrading to LLVM-9 > > > > fixes the issue ? > > > > > > > > > > > > On Wed, 10 Jun 2020 14:50:27 -0700 Elerion <elerion1000@gmail.com> wrote: > > > > > > > > > Never mind, I fixed it by downgrading to Clang 9. > > > > > > > > > > It appears to be an issue with Clang/LLVM 10+ > > > > > > > > > > https://github.com/cilium/ebpf/issues/43 > > > > > > This is newer Clang recording that function is global, not static. > > > libbpf is sanitizing BTF to remove this flag, if kernel doesn't > > > support this. But given this is re-implementation of libbpf, that's > > > probably not happening, right? > > > > > > > > > > > > > On Wed, Jun 10, 2020 at 2:38 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > > > > > > > > > > > Elerion <elerion1000@gmail.com> writes: > > > > > > > > > > > > > [69] FUNC xdp_program type_id=68 vlen != 0 > > > > > > > > > > > > 'vlen != 0' is the error. Not sure why you hit that; what's the output > > > > > > of 'bpftool btf dump file yourprog.o' ? > > > > > > > > > > > > -Toke > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Jesper Dangaard Brouer > > > > MSc.CS, Principal Kernel Engineer at Red Hat > > > > LinkedIn: http://www.linkedin.com/in/brouer > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-06-11 21:11 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-10 21:01 Error loading xdp program that worked with bpf_load Elerion 2020-06-10 21:06 ` Toke Høiland-Jørgensen 2020-06-10 21:08 ` Elerion 2020-06-10 21:37 ` Toke Høiland-Jørgensen 2020-06-10 21:44 ` Elerion 2020-06-10 21:50 ` Elerion 2020-06-11 10:59 ` Jesper Dangaard Brouer 2020-06-11 16:34 ` Andrii Nakryiko 2020-06-11 16:39 ` [iovisor-dev] " Alexei Starovoitov 2020-06-11 20:40 ` Elerion 2020-06-11 20:46 ` Andrii Nakryiko 2020-06-11 21:11 ` Elerion
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).