bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Quentin Monnet <quentin@isovalent.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	John Fastabend <john.fastabend@gmail.com>
Subject: Re: [PATCH bpf-next v2 2/5] libbpf: rename btf__get_from_id() as btf__load_from_kernel_by_id()
Date: Fri, 23 Jul 2021 10:31:17 +0100	[thread overview]
Message-ID: <88d3cd19-5985-ad73-5f23-4f6f7d1b1be2@isovalent.com> (raw)
In-Reply-To: <CAEf4BzZqEZLt0_qgmniY-hqgEg7q0ur0Z5U0r8KFTwSz=2StSg@mail.gmail.com>

2021-07-22 17:39 UTC-0700 ~ Andrii Nakryiko <andrii.nakryiko@gmail.com>
> On Wed, Jul 21, 2021 at 8:38 AM Quentin Monnet <quentin@isovalent.com> wrote:
>>
>> Rename function btf__get_from_id() as btf__load_from_kernel_by_id() to
>> better indicate what the function does. Change the new function so that,
>> instead of requiring a pointer to the pointer to update and returning
>> with an error code, it takes a single argument (the id of the BTF
>> object) and returns the corresponding pointer. This is more in line with
>> the existing constructors.
>>
>> The other tools calling the deprecated btf__get_from_id() function will
>> be updated in a future commit.
>>
>> References:
>>
>> - https://github.com/libbpf/libbpf/issues/278
>> - https://github.com/libbpf/libbpf/wiki/Libbpf:-the-road-to-v1.0#btfh-apis
>>
>> v2:
>> - Instead of a simple renaming, change the new function to make it
>>   return the pointer to the btf struct.
>> - API v0.5.0 instead of v0.6.0.
> 
> We generally keep such version changes to cover letters. It keeps each
> individual commit clean and collects full history in the cover letter
> which becomes a body of merge commit when the whole patch set is
> applied. For next revision please consolidate the history in the cover
> letter. Thanks!

OK will do.
I've seen other folks detailing the changes on individual patches, and
done so in the past, although it's true the current trend is to have it
in the cover letter (and I understand the motivation).

> 
>>
>> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
>> Acked-by: John Fastabend <john.fastabend@gmail.com>
>> ---
>>  tools/lib/bpf/btf.c      | 25 +++++++++++++++++--------
>>  tools/lib/bpf/btf.h      |  1 +
>>  tools/lib/bpf/libbpf.c   |  5 +++--
>>  tools/lib/bpf/libbpf.map |  1 +
>>  4 files changed, 22 insertions(+), 10 deletions(-)
>>
>> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
>> index 7e0de560490e..6654bdee7ad7 100644
>> --- a/tools/lib/bpf/btf.c
>> +++ b/tools/lib/bpf/btf.c
>> @@ -1383,21 +1383,30 @@ struct btf *btf_get_from_fd(int btf_fd, struct btf *base_btf)
>>         return btf;
>>  }
>>
>> +struct btf *btf__load_from_kernel_by_id(__u32 id)
>> +{
>> +       struct btf *btf;
>> +       int btf_fd;
>> +
>> +       btf_fd = bpf_btf_get_fd_by_id(id);
>> +       if (btf_fd < 0)
>> +               return ERR_PTR(-errno);
> 
> please use libbpf_err_ptr() for consistency, see
> bpf_object__open_mem() for an example

I can do that, but I'll need to uncouple btf__get_from_id() from the new
function. If it calls btf__load_from_kernel_by_id() and
LIBBPF_STRICT_CLEAN_PTRS is set, it would change its return value.

> 
>> +
>> +       btf = btf_get_from_fd(btf_fd, NULL);
>> +       close(btf_fd);
>> +
>> +       return libbpf_ptr(btf);
>> +}
>> +
>>  int btf__get_from_id(__u32 id, struct btf **btf)
>>  {
>>         struct btf *res;
>> -       int err, btf_fd;
>> +       int err;
>>
>>         *btf = NULL;
>> -       btf_fd = bpf_btf_get_fd_by_id(id);
>> -       if (btf_fd < 0)
>> -               return libbpf_err(-errno);
>> -
>> -       res = btf_get_from_fd(btf_fd, NULL);
>> +       res = btf__load_from_kernel_by_id(id);
>>         err = libbpf_get_error(res);
>>
>> -       close(btf_fd);
>> -
>>         if (err)
>>                 return libbpf_err(err);
>>
>> diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
>> index fd8a21d936ef..3db9446bc133 100644
>> --- a/tools/lib/bpf/btf.h
>> +++ b/tools/lib/bpf/btf.h
>> @@ -68,6 +68,7 @@ LIBBPF_API const void *btf__get_raw_data(const struct btf *btf, __u32 *size);
>>  LIBBPF_API const char *btf__name_by_offset(const struct btf *btf, __u32 offset);
>>  LIBBPF_API const char *btf__str_by_offset(const struct btf *btf, __u32 offset);
>>  LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
>> +LIBBPF_API struct btf *btf__load_from_kernel_by_id(__u32 id);
> 
> let's move this definition to after btf__parse() to keep all
> "constructors" together (we can move btf__get_from_id() there for
> completeness as well, I suppose).

I thought about that but wasn't sure, OK will do.

> 
>>  LIBBPF_API int btf__get_map_kv_tids(const struct btf *btf, const char *map_name,
>>                                     __u32 expected_key_size,
>>                                     __u32 expected_value_size,
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index 242e97892043..eff005b1eba1 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -9576,8 +9576,8 @@ static int libbpf_find_prog_btf_id(const char *name, __u32 attach_prog_fd)
>>  {
>>         struct bpf_prog_info_linear *info_linear;
>>         struct bpf_prog_info *info;
>> -       struct btf *btf = NULL;
>>         int err = -EINVAL;
>> +       struct btf *btf;
>>
>>         info_linear = bpf_program__get_prog_info_linear(attach_prog_fd, 0);
>>         err = libbpf_get_error(info_linear);
>> @@ -9591,7 +9591,8 @@ static int libbpf_find_prog_btf_id(const char *name, __u32 attach_prog_fd)
>>                 pr_warn("The target program doesn't have BTF\n");
>>                 goto out;
>>         }
>> -       if (btf__get_from_id(info->btf_id, &btf)) {
>> +       btf = btf__load_from_kernel_by_id(info->btf_id);
>> +       if (libbpf_get_error(btf)) {
> 
> there seems to be a bug in existing code and you are keeping it. On
> error err will be 0. Let's fix it. Same for above if (!info->btf_id),
> please fix that as well while you are at it.

Oh right, I saw that err was initialised at -EINVAL and did not notice
it was changed for the info_linear. I'll address it.

  reply	other threads:[~2021-07-23  9:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21 15:38 [PATCH bpf-next v2 0/5] libbpf: rename btf__get_from_id() and btf__load() APIs, support split BTF Quentin Monnet
2021-07-21 15:38 ` [PATCH bpf-next v2 1/5] libbpf: rename btf__load() as btf__load_into_kernel() Quentin Monnet
2021-07-21 15:38 ` [PATCH bpf-next v2 2/5] libbpf: rename btf__get_from_id() as btf__load_from_kernel_by_id() Quentin Monnet
2021-07-23  0:39   ` Andrii Nakryiko
2021-07-23  9:31     ` Quentin Monnet [this message]
2021-07-23 15:54       ` Andrii Nakryiko
2021-07-23 16:13         ` Quentin Monnet
2021-07-23 17:18           ` Andrii Nakryiko
2021-07-23 17:44             ` Quentin Monnet
2021-07-21 15:38 ` [PATCH bpf-next v2 3/5] tools: replace btf__get_from_id() with btf__load_from_kernel_by_id() Quentin Monnet
2021-07-23  0:48   ` Andrii Nakryiko
2021-07-23  9:52     ` Quentin Monnet
2021-07-23 15:57       ` Andrii Nakryiko
2021-07-23 16:17         ` Quentin Monnet
2021-07-21 15:38 ` [PATCH bpf-next v2 4/5] libbpf: add split BTF support for btf__load_from_kernel_by_id() Quentin Monnet
2021-07-23  0:49   ` Andrii Nakryiko
2021-07-21 15:38 ` [PATCH bpf-next v2 5/5] tools: bpftool: support dumping split BTF by id Quentin Monnet
2021-07-23  0:58 ` [PATCH bpf-next v2 0/5] libbpf: rename btf__get_from_id() and btf__load() APIs, support split BTF Andrii Nakryiko
2021-07-23  2:45   ` Andrii Nakryiko
2021-07-23  9:58     ` Quentin Monnet
2021-07-23 15:51       ` Andrii Nakryiko
2021-07-27 11:39         ` Quentin Monnet
2021-07-27 20:49           ` Andrii Nakryiko
2021-07-28 21:54             ` Quentin Monnet
2021-07-28 22:29               ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=88d3cd19-5985-ad73-5f23-4f6f7d1b1be2@isovalent.com \
    --to=quentin@isovalent.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).