From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Leblond Subject: net-next libbpf broken on prev kernel release Date: Thu, 14 Dec 2017 10:16:28 +0100 Message-ID: <1513242988.1668.51.camel@regit.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit To: netdev@vger.kernel.org, Martin KaFai Lau Return-path: Received: from home.regit.org ([37.187.126.138]:55876 "EHLO home.regit.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750737AbdLNJQe (ORCPT ); Thu, 14 Dec 2017 04:16:34 -0500 Sender: netdev-owner@vger.kernel.org List-ID: 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 Wed Sep 27 14:37:54 2017 -0700 committer David S. Miller 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