Re: Re: [PATCH bpf] libbpf: soften BTF map error

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

 



On 8/17/23 07:17, Daniel Borkmann wrote:
On 8/16/23 7:30 PM, Martin Kelly wrote:
For map-in-map types, the first time the map is loaded, we get a scary
error looking like this:

libbpf: bpf_create_map_xattr(map_name):ERROR: strerror_r(-524)=22(-524). Retrying without BTF.

On the second try without BTF, everything works fine. However, as this
is logged at error level, it looks needlessly scary to users. Soften
this to be at debug level; if the second attempt still fails, we'll
still get an error as expected.

Signed-off-by: Martin Kelly <martin.kelly@xxxxxxxxxxxxxxx>

nit: $subj should be for bpf-next instead of bpf

I had purposefully sent to "bpf" instead of "bpf-next" as it felt like a fix, but I'm fine with "bpf-next" instead if that's better.


---
  tools/lib/bpf/libbpf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index b14a4376a86e..0ca0c8d01707 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -5123,7 +5123,7 @@ static int bpf_object__create_map(struct bpf_object *obj, struct bpf_map *map, b
            err = -errno;
          cp = libbpf_strerror_r(err, errmsg, sizeof(errmsg));
-        pr_warn("Error in bpf_create_map_xattr(%s):%s(%d). Retrying without BTF.\n", +        pr_debug("bpf_create_map_xattr(%s):%s(%d). Retrying without BTF.\n",
              map->name, cp, err);

There are also several other places with pr_warns about BTF when loading an obj. Did you audit them as well under !BTF kernel? nit: Why changing the fmt string itself,
looked ok as-is, no?

This message is actually printed even for a BTF-supported kernel. Basically, the first call to bpf_create_map_xattr using BTF *always* fails for map-in-map types, printing this message, and then the second always succeeds. So this isn't really about BTF support but simply about an over-zealous message.

I changed the format string because calling this an "Error" feels (to me) unnecessarily alarming, given that this is totally normal behavior. I'm OK keeping the "Error in" part if you think that's better. The most important thing to me was that, when the program loads successfully, we shouldn't be logging to stderr and scaring the user.

Let me know if you'd like me to keep the "Error in" part for a v2 patch.


There is also libbpf_needs_btf(obj), perhaps this could be left as pr_warn similar
as in bpf_object__init_btf() - or would this still trigger in your case?

I think this one should stay as a warning, as it looks like the code path is a fatal error, and if you try to load a BTF-requiring program but don't have BTF, that seems like an error to me. This patch was more about an error being logged 100% of the time in a totally normal, non-fatal, BTF-supported case due to the quirks of map-in-map types and BTF.


          create_attr.btf_fd = 0;
          create_attr.btf_key_type_id = 0;


Thanks,
Daniel




[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