Re: [PATCH v5] bpf/scripts: add an error if the correct number of helpers are not generated

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 12/01/2022 11:04, Quentin Monnet wrote:
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, i have sent v6 which raises an Exception. No point in writing to the auto-generated header/rst if the script raises an Exception as the actual helpers wont be written so i have moved the check to the constructor.

Thanks,
Quentin




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux