Hello,
It seems that the following patch did break libbpf (in net-next
version) which is not able to load anymore a program on a 4.14:
tree 5096ddd73981e33a2164606461a45b56a189889c
parent ad5b177bd73f5107d97c36f56395c4281fb6f089
author Martin KaFai Lau <ka...@fb.com> Wed Sep 27 14:37:54 2017 -0700
committer David S. Miller <da...@davemloft.net> Fri Sep 29 06:17:05 2017 +0100
bpf: libbpf: Provide basic API support to specify BPF obj name
The problem comes from
-int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
- size_t insns_cnt, const char *license,
- __u32 kern_version, char *log_buf, size_t log_buf_sz)
+int bpf_load_program_name(enum bpf_prog_type type, const char *name,
+ const struct bpf_insn *insns,
+ size_t insns_cnt, const char *license,
+ __u32 kern_version, char *log_buf,
+ size_t log_buf_sz)
{
int fd;
union bpf_attr attr;
+ __u32 name_len = name ? strlen(name) : 0;
bzero(&attr, sizeof(attr));
attr.prog_type = type;
@@ -130,6 +151,7 @@ int bpf_load_program(enum bpf_prog_type type, const struct
bpf_insn *insns,
attr.log_size = 0;
attr.log_level = 0;
attr.kern_version = kern_version;
+ memcpy(attr.prog_name, name, min(name_len, BPF_OBJ_NAME_LEN - 1));
If I comment the memcpy then the eBPF program is loading correctly.
Is this a wanted behavior to have libbpf that needs to be in sync with
kernel ? or should it be fixed ?
BR,
--
Eric Leblond <e...@regit.org>
