Message-ID: <564AA4B6.5070107@huawei.com>
Date:	Tue, 17 Nov 2015 11:53:26 +0800
From:	"Wangnan (F)" <wangnan0@...wei.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
CC:	<masami.hiramatsu.pt@...achi.com>, <ast@...nel.org>,
	<lizefan@...wei.com>, <pi3orama@....com>,
	<linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...nel.org>,
	He Kuang <hekuang@...wei.com>
Subject: Re: [PATCH 07/13] bpf tools: Load a program with different instances
 using preprocessor



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 <wangnan0@...wei.com>
>> Signed-off-by: He Kuang <hekuang@...wei.com>
>> Cc: Alexei Starovoitov <ast@...nel.org>
>> Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
>> Cc: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
>> Cc: Zefan Li <lizefan@...wei.com>
>> Cc: pi3orama@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists