Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752161AbbKQDyR (ORCPT ); Mon, 16 Nov 2015 22:54:17 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:3235 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751543AbbKQDyQ (ORCPT ); Mon, 16 Nov 2015 22:54:16 -0500 Message-ID: <564AA4B6.5070107@huawei.com> Date: Tue, 17 Nov 2015 11:53:26 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Arnaldo Carvalho de Melo CC: , , , , , Ingo Molnar , He Kuang Subject: Re: [PATCH 07/13] bpf tools: Load a program with different instances using preprocessor References: <1447675815-166222-1-git-send-email-wangnan0@huawei.com> <1447675815-166222-8-git-send-email-wangnan0@huawei.com> <20151116190259.GA11993@kernel.org> In-Reply-To: <20151116190259.GA11993@kernel.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.564AA4D8.0100,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7f7d5357514624e4d00ee91812560eda Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5583 Lines: 148 On 2015/11/17 3:02, Arnaldo Carvalho de Melo wrote: > Em Mon, Nov 16, 2015 at 12:10:09PM +0000, Wang Nan escreveu: >> This patch is a preparation for BPF prologue support which allows >> generating a series of BPF bytecode for fetching kernel data before >> calling program code. With the newly introduced multiple instances >> support, perf is able to create different prologues for different >> kprobe points. >> >> Before this patch, a bpf_program can be loaded into kernel only once, >> and get the only resuling fd. What this patch done is to allow creating >> and loading different variants of one bpf_program, then fetching their >> fds. >> >> Here describe the basic idea in this patch. The detail description of >> the newly introduced APIs can be found in comment in the patch body. >> >> The key of this patch is the new mechanism in bpf_program__load(). >> Instead of loading BPF program into kernel directly, it calls a >> 'pre-processor' to generate program instances which would be final >> loaded into kernel based on the original code. To enable multiple >> instances generation, libbpf passes an index to the pre-processor >> so it know which instance is being loaded. >> >> Pre-processor should be passed from libbpf's user (perf) using >> bpf_program__set_prep(). The number of instances and the relationship >> between indics and the target instance should be clear when calling >> bpf_program__set_prep(). >> >> To retrive fd for a specific instance of a program, >> bpf_program__nth_fd() is introduced. It return the resuling fd >> according to index. >> >> Signed-off-by: Wang Nan >> Signed-off-by: He Kuang >> Cc: Alexei Starovoitov >> Cc: Arnaldo Carvalho de Melo >> Cc: Masami Hiramatsu >> Cc: Zefan Li >> Cc: pi3orama@163.com >> --- >> tools/lib/bpf/libbpf.c | 145 ++++++++++++++++++++++++++++++++++++++++++++++--- >> tools/lib/bpf/libbpf.h | 64 ++++++++++++++++++++++ >> 2 files changed, 200 insertions(+), 9 deletions(-) >> >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c >> index e176bad..fcfa39f 100644 >> --- a/tools/lib/bpf/libbpf.c >> +++ b/tools/lib/bpf/libbpf.c >> @@ -152,7 +152,11 @@ struct bpf_program { >> } *reloc_desc; >> int nr_reloc; >> >> - int fd; >> + struct { >> + int nr; >> + int *fds; >> + } instances; >> + bpf_program_prep_t preprocessor; >> >> struct bpf_object *obj; >> void *priv; >> @@ -206,10 +210,24 @@ struct bpf_object { >> >> static void bpf_program__unload(struct bpf_program *prog) >> { >> + int i; >> + >> if (!prog) >> return; >> >> - zclose(prog->fd); >> + /* >> + * If the object is opened but the program is never loaded, >> + * it is possible that prog->instances.nr == -1. >> + */ >> + if (prog->instances.nr > 0) { >> + for (i = 0; i < prog->instances.nr; i++) >> + zclose(prog->instances.fds[i]); >> + } else if (prog->instances.nr != -1) >> + pr_warning("Internal error: instances.nr is %d\n", >> + prog->instances.nr); >> + > > Multi line if/else blocks should be under {}, like you did for the if > part, but forgot to do for the else part. > > I'm fixing this up, but please try to be consistent about these details > next time, more below. > >> + prog->instances.nr = -1; >> + zfree(&prog->instances.fds); >> } >> >> static void bpf_program__exit(struct bpf_program *prog) >> @@ -260,7 +278,8 @@ bpf_program__init(void *data, size_t size, char *name, int idx, >> memcpy(prog->insns, data, >> prog->insns_cnt * sizeof(struct bpf_insn)); >> prog->idx = idx; >> - prog->fd = -1; >> + prog->instances.fds = NULL; >> + prog->instances.nr = -1; >> >> return 0; >> errout: >> @@ -860,13 +879,73 @@ static int >> bpf_program__load(struct bpf_program *prog, >> char *license, u32 kern_version) >> { >> - int err, fd; >> + int err = 0, fd, i; >> + >> + if (prog->instances.nr < 0 || !prog->instances.fds) { >> + if (prog->preprocessor) { >> + pr_warning("Internal error: can't load program '%s'\n", >> + prog->section_name); >> + return -LIBBPF_ERRNO__INTERNAL; >> + } > Those errors I think should come with some prefix to provide more > context about what kind of "internal error" is this, in some cases I am > adding "BPF", but not in all, more to think about how to make this > clearer. In bpf_program__set_prep, the parameters are already checked, so if prog->preprocessor is set (!= NULL), the conditions in 'if' statement should never be satisified. Therefore it must an internal error (bug?) in libbpf. All LIBBPF error code except LIBBPF_ERRNO__INTERNAL can be triggered by user by some way (for example, providing an invalid object file). Therefore, we need to tell them the reason of failure formally, let error messages hint users how to fix their fault. LIBBPF_ERRNO__INTERNAL is different. If it raise there must be a bug in libbpf or perf (incorrectly use libbpf's API). In this case, we have already provided pr_{debug,warning} to developers. In my opinion, formally reporting is not require because perf's user don't need to be told too much about the internal implementation (it causes confusion). All they need to know is "there is a bug, let's report it with '-v' output". Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/