From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01C42C07E95 for ; Wed, 7 Jul 2021 20:58:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D8CFA61CC9 for ; Wed, 7 Jul 2021 20:58:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232020AbhGGVAk (ORCPT ); Wed, 7 Jul 2021 17:00:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230178AbhGGVAk (ORCPT ); Wed, 7 Jul 2021 17:00:40 -0400 Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58CFDC061574; Wed, 7 Jul 2021 13:57:59 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id y38so5351016ybi.1; Wed, 07 Jul 2021 13:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m1nWFHfORcbPdTsbgHYGUaQxpYC/3l7L+MYxNakAZpg=; b=M0cWHNpid6NNkynCPE2Cec9kLqdEdL7aKrJ0VQbCHizASblHv9ByqrwoYnlHGWQw/Z TfQgbCdNPSTdgeDqB+Uqwf72H7JgGuzIq/OjMxoIzQo7xXFT1M9fmpEBXltdGe5JhQjn aVDJYbaGnVup6vQEgNf5WXkIgh30vsqQUXg4JueHw3Yj9ZWDf68HylQ6tMvDyBItldEe 9KJEdr2hT80lvfAzdG5Ww4RtHwpvG2Q0H862aGK8S5qTJlZ/ok0EHzMBGgO2Ltmo127r P/Px/JdQ98Ukemt5MHLxOmCBvabbQS4IKrhvdaLg+H1UHgVcaWrQiKU3GRVKOtOm5qmt yRYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m1nWFHfORcbPdTsbgHYGUaQxpYC/3l7L+MYxNakAZpg=; b=YDrIu/qiduVBToyPXMUVrWXhGT9Jr5n6j798aW7YLXPrO7TRbro0jBjdywseTgB+4Z 9pkQkV9/gYo8zsRqges29BeIxZLFcnMjlxBxMNi8k1zz2NKXhRncSgaqW23MOsWdJUNo V66CEJO4MISwWFRzD5MfREagzfKYEa0HjAlRSdINz2w3ebXaujVOSujofbOh5o22/yg7 Z0cs7+JURjBceVacr+nJ/CHuWeaaVocs0Gotrfoyymx+xTfYBiuzrF+fqirJuLFC7zuH AXSFpKsQrigXIkT61xGbqmEu4B96WADnMpSdslJotTlh1Z9j8ZzIbBQzsECIFcoDu7l9 iB8g== X-Gm-Message-State: AOAM533R2KPic7AxljvC3zaBPYLrox+xxsh2JWbKaNM3V2CqjxOnVsuE kk1AqsMfpEJRCFkqQpeanN1OSpM6MSs4fMCD+c0= X-Google-Smtp-Source: ABdhPJysgjeZc92yss6nOlW6MfGYOC8wccAWm6AilKDpGGEIOIazJuAonm1eQ9+dfonueuqRwFOazrp6R/DAlaw8HSA= X-Received: by 2002:a25:9942:: with SMTP id n2mr34880526ybo.230.1625691478671; Wed, 07 Jul 2021 13:57:58 -0700 (PDT) MIME-Version: 1.0 References: <1624507409-114522-1-git-send-email-chengshuyi@linux.alibaba.com> <8ca15bab-ec66-657d-570a-278deff0b1a3@iogearbox.net> In-Reply-To: <8ca15bab-ec66-657d-570a-278deff0b1a3@iogearbox.net> From: Andrii Nakryiko Date: Wed, 7 Jul 2021 13:57:47 -0700 Message-ID: Subject: Re: [PATCH bpf-next] libbpf: Introduce 'custom_btf_path' to 'bpf_obj_open_opts'. To: Daniel Borkmann Cc: Shuyi Cheng , Alexei Starovoitov , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , Networking , bpf , open list , kernel-janitors@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Jun 24, 2021 at 8:06 AM Daniel Borkmann wrote: > > On 6/24/21 6:03 AM, Shuyi Cheng wrote: > > In order to enable the older kernel to use the CO-RE feature, load the > > vmlinux btf of the specified path. > > > > Learn from Andrii's comments in [0], add the custom_btf_path parameter > > to bpf_obj_open_opts, you can directly use the skeleton's > > _bpf__open_opts function to pass in the custom_btf_path > > parameter. > > > > Prior to this, there was also a developer who provided a patch with > > similar functions. It is a pity that the follow-up did not continue to > > advance. See [1]. > > > > [0]https://lore.kernel.org/bpf/CAEf4BzbJZLjNoiK8_VfeVg_Vrg=9iYFv+po-38SMe=UzwDKJ=Q@mail.gmail.com/#t > > [1]https://yhbt.net/lore/all/CAEf4Bzbgw49w2PtowsrzKQNcxD4fZRE6AKByX-5-dMo-+oWHHA@mail.gmail.com/ > > > > Signed-off-by: Shuyi Cheng > > --- > > tools/lib/bpf/libbpf.c | 23 ++++++++++++++++++++--- > > tools/lib/bpf/libbpf.h | 6 +++++- > > 2 files changed, 25 insertions(+), 4 deletions(-) > > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > > index 1e04ce7..518b19f 100644 > > --- a/tools/lib/bpf/libbpf.c > > +++ b/tools/lib/bpf/libbpf.c > > @@ -509,6 +509,8 @@ struct bpf_object { > > void *priv; > > bpf_object_clear_priv_t clear_priv; > > > > + char *custom_btf_path; > > + > > nit: This should rather go to the 'Parse and load BTF vmlinux if any of [...]' > section of struct bpf_object, and for consistency, I'd keep the btf_ prefix, > like: char *btf_custom_path > > > char path[]; > > }; > > #define obj_elf_valid(o) ((o)->efile.elf) > > @@ -2679,8 +2681,15 @@ static int bpf_object__load_vmlinux_btf(struct bpf_object *obj, bool force) > > if (!force && !obj_needs_vmlinux_btf(obj)) > > return 0; > > > > - obj->btf_vmlinux = libbpf_find_kernel_btf(); > > - err = libbpf_get_error(obj->btf_vmlinux); > > + if (obj->custom_btf_path) { > > + obj->btf_vmlinux = btf__parse(obj->custom_btf_path, NULL); > > + err = libbpf_get_error(obj->btf_vmlinux); > > + pr_debug("loading custom vmlinux BTF '%s': %d\n", obj->custom_btf_path, err); > > + } else { > > + obj->btf_vmlinux = libbpf_find_kernel_btf(); > > + err = libbpf_get_error(obj->btf_vmlinux); > > + } > > Couldn't we do something like (only compile-tested): I wonder what are the benefits of this approach, though. My expectation is that if the user specifies a custom BTF path and BTF is missing then the whole bpf_object load process should fail, but in this case it will be silently ignored. Also, if custom BTF is specified, that custom BTF has to be used even if /sys/kernel/btf/vmlinux is present, but the patch below will still prefer /sys/kernel/btf/vmlinux. So the semantics is different. I'm not saying it's wrong, but I think it means we need to discuss what behavior we are after first. > > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c > index b46760b93bb4..5b88ce3e483c 100644 > --- a/tools/lib/bpf/btf.c > +++ b/tools/lib/bpf/btf.c > @@ -4394,7 +4394,7 @@ static int btf_dedup_remap_types(struct btf_dedup *d) > * Probe few well-known locations for vmlinux kernel image and try to load BTF > * data out of it to use for target BTF. > */ > -struct btf *libbpf_find_kernel_btf(void) > +static struct btf *__libbpf_find_kernel_btf(char *btf_custom_path) > { > struct { > const char *path_fmt; [...]