2022-01-12 10:19 UTC+0000 ~ Usama Arif <usama.arif@xxxxxxxxxxxxx>
>
>
> On 12/01/2022 10:01, Quentin Monnet wrote:
>> 2022-01-11 18:44 UTC+0000 ~ Usama Arif <usama.arif@xxxxxxxxxxxxx>
>>> Currently bpf_helper_defs.h and the bpf helpers man page are
>>> auto-generated
>>> using function documentation present in bpf.h. If the documentation
>>> for the
>>> helper is missing or doesn't follow a specific format for e.g. if a
>>> function
>>> is documented as:
>>> * long bpf_kallsyms_lookup_name( const char *name, int name_sz, int
>>> flags, u64 *res )
>>> instead of
>>> * long bpf_kallsyms_lookup_name(const char *name, int name_sz, int
>>> flags, u64 *res)
>>> (notice the extra space at the start and end of function arguments)
>>> then that helper is not dumped in the auto-generated header and
>>> results in
>>> an invalid call during eBPF runtime, even if all the code specific to
>>> the
>>> helper is correct.
>>>
>>> This patch checks the number of functions documented within the
>>> header file
>>> with those present as part of #define __BPF_FUNC_MAPPER and generates an
>>> error in the header file and the man page if they don't match. It is not
>>> needed with the currently documented upstream functions, but can help in
>>> debugging when developing new helpers when there might be missing or
>>> misformatted documentation.
>>>
>>> Signed-off-by: Usama Arif <usama.arif@xxxxxxxxxxxxx>
>>>
>>> ---
>>> v4->v5:
>>> - Converted warning to error incase of missing/misformatted helper doc
>>> (suggested by Song Liu)
>>
>> I don't think it was converted to an error in the sense that Song meant
>> it? Unless I'm missing something you simply changed the message so that
>> it prints "error" instead of "warning", but the script still goes on
>> without returning any error code, and a failure won't be detected by the
>> CI for example.
>>
>> Could you make the script break out on errors, and print a message to
>> stderr so that it's visible even if the generated output is redirected
>> to a file, please?
>>
>
> It does now print an error to stdout while building an eBPF application.
> For e.g. if you introduce a space in the doc as in the commit message like:
>
> diff --git a/tools/include/uapi/linux/bpf.h
> b/tools/include/uapi/linux/bpf.h
> index ba5af15e25f5..5bf80dbb820b 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
> @@ -4908,7 +4908,7 @@ union bpf_attr {
> *
> * **-ENOENT** if architecture does not support branch
> records.
> *
> - * long bpf_trace_vprintk(const char *fmt, u32 fmt_size, const void
> *data, u32 data_len)
> + * long bpf_trace_vprintk( const char *fmt, u32 fmt_size, const void
> *data, u32 data_len)
> * Description
> * Behaves like **bpf_trace_printk**\ () helper, but takes
> an array of u64
> * to format and can handle more format args as a result.
> @@ -4938,6 +4938,12 @@ union bpf_attr {
> * **-ENOENT** if symbol is not found.
> *
> * **-EPERM** if caller does not have permission to obtain
> kernel address.
>
> and build samples/bpf:
>
> make LLVM_STRIP=llvm-strip-13 M=samples/bpf > /tmp/samplesbuild.out
>
> you get the following at stderr returning an error code
>
> make[2]: *** [Makefile:186:
> /data/usaari01/ebpf/linux/samples/bpf/bpftool/pid_iter.bpf.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> In file included from skeleton/profiler.bpf.c:4:
> In file included from
> /data/usaari01/ebpf/linux/samples/bpf/bpftool//bootstrap/libbpf//include/bpf/bpf_helpers.h:11:
>
> /data/usaari01/ebpf/linux/samples/bpf/bpftool//bootstrap/libbpf//include/bpf/bpf_helper_defs.h:5:2:
> error: The number of unique helpers in description (176) don't match the
> number of unique helpers defined in __BPF_FUNC_MAPPER (180)
> #error The number of unique helpers in description (176) don't match the
> number of unique helpers defined in __BPF_FUNC_MAPPER (180)
> ^
> /data/usaari01/ebpf/linux/samples/bpf/bpftool//bootstrap/libbpf//include/bpf/bpf_helper_defs.h:7:2:
> error: The description for FN(trace_vprintk) is not present or formatted
> correctly.
> #error The description for FN(trace_vprintk) is not present or formatted
> correctly.
> ^
Right, my bad, I tried your patch to generate the header but didn't go
so far as to include it and try to compile a program.
> But i am guessing that you want an error while the script is run as well?
> If we do this:
> diff --git a/scripts/bpf_doc.py b/scripts/bpf_doc.py
> index adf08fa963a4..4ce982ce58f2 100755
> --- a/scripts/bpf_doc.py
> +++ b/scripts/bpf_doc.py
> @@ -397,6 +397,7 @@ HELPERS
> The description for %s is not present or formatted correctly.
> ''' % (self.define_unique_helpers[nr_desc_unique_helpers])
> print(header_error)
> + print(header_error, file = sys.stderr)
>
> print(header_description)
>
> @@ -693,6 +694,7 @@ class PrinterHelpers(Printer):
> #error The description for %s is not present or formatted correctly.
> ''' % (self.define_unique_helpers[nr_desc_unique_helpers])
> print(header_error)
> + print(header_error, file = sys.stderr)
>
> for fwd in self.type_fwds:
> print('%s;' % fwd)
>
> then an error will be printed while the script is run and also later
> while the eBPF application is compiled. I can send this in next version
> if thats the preference?
Yes, this is what I meant. From my point of view it would be best if we
had this message, and also if we could make bpf_doc.py raise an
Exception on such errors. Given that we can tell at this step already
that compiling will fail, we should as well break the workflow here,
there's not much point in carrying on and calling the compiler.
Thanks,
Quentin
