net-next libbpf broken on prev kernel release

[Eric Leblond <eric@regit.org>]

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 <kafai@fb.com> Wed Sep 27 14:37:54 2017 -0700
committer David S. Miller <davem@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 <eric@regit.org>