Error loading xdp program that worked with bpf_load

Error loading xdp program that worked with bpf_load

[Elerion]

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

Re: Error loading xdp program that worked with bpf_load

[Toke Høiland-Jørgensen]

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

Re: Error loading xdp program that worked with bpf_load

[Elerion]

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
>

Re: Error loading xdp program that worked with bpf_load

[Toke Høiland-Jørgensen]

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

Re: Error loading xdp program that worked with bpf_load

[Elerion]

[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
>

Re: Error loading xdp program that worked with bpf_load

[Elerion]

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
>

Re: Error loading xdp program that worked with bpf_load

[Jesper Dangaard Brouer]

(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

Re: Error loading xdp program that worked with bpf_load

[Andrii Nakryiko]

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
>

Re: [iovisor-dev] Error loading xdp program that worked with bpf_load

[Alexei Starovoitov]

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?

Re: Error loading xdp program that worked with bpf_load

[Elerion]

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
> >

Re: Error loading xdp program that worked with bpf_load

[Andrii Nakryiko]

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
> > >

Re: Error loading xdp program that worked with bpf_load

[Elerion]

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
> > > >