All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Hwang <leon.hwang@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
	daniel@iogearbox.net
Subject: Re: [RFC PATCH bpf-next v3 09/10] libbpf: Add common attr support for map_create
Date: Thu, 9 Oct 2025 13:35:36 +0800	[thread overview]
Message-ID: <16e155c2-294a-48b6-9339-75aa4edf8048@linux.dev> (raw)
In-Reply-To: <CAEf4Bzaw9cboFSf1OXmD84S7pKaeyj=bcQg_diUzGwAkFsjUgg@mail.gmail.com>



On 7/10/25 07:08, Andrii Nakryiko wrote:
> On Thu, Oct 2, 2025 at 8:49 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> With the previous commit adding common attribute support for
>> BPF_MAP_CREATE, it is now possible to retrieve detailed error messages
>> when map creation fails by using the 'log_buf' field from the common
>> attributes.
>>
>> Extend 'bpf_map_create_opts' with these new fields, 'log_buf', 'log_size'
>> , 'log_level' and 'log_true_size', allowing users to capture and inspect
>
> comma
>

Ack.

>> those log messages.
>>
>> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
>> ---
>>  tools/lib/bpf/bpf.c | 17 +++++++++++++++--
>>  tools/lib/bpf/bpf.h |  9 +++++++--
>>  2 files changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>> index 9cd79beb13a2d..ca66fcdb3f49f 100644
>> --- a/tools/lib/bpf/bpf.c
>> +++ b/tools/lib/bpf/bpf.c
>> @@ -203,10 +203,13 @@ int bpf_map_create(enum bpf_map_type map_type,
>>                    __u32 key_size,
>>                    __u32 value_size,
>>                    __u32 max_entries,
>> -                  const struct bpf_map_create_opts *opts)
>> +                  struct bpf_map_create_opts *opts)
>
> this is a breaking change, see below
>
>>  {
>>         const size_t attr_sz = offsetofend(union bpf_attr, excl_prog_hash_size);
>> +       const size_t common_attrs_sz = sizeof(struct bpf_common_attr);
>> +       struct bpf_common_attr common_attrs;
>>         union bpf_attr attr;
>> +       const char *log_buf;
>>         int fd;
>>
>>         bump_rlimit_memlock();
>> @@ -239,7 +242,17 @@ int bpf_map_create(enum bpf_map_type map_type,
>>         attr.excl_prog_hash = ptr_to_u64(OPTS_GET(opts, excl_prog_hash, NULL));
>>         attr.excl_prog_hash_size = OPTS_GET(opts, excl_prog_hash_size, 0);
>>
>> -       fd = sys_bpf_fd(BPF_MAP_CREATE, &attr, attr_sz);
>> +       log_buf = OPTS_GET(opts, log_buf, NULL);
>> +       if (log_buf && feat_supported(NULL, FEAT_EXTENDED_SYSCALL)) {
>> +               memset(&common_attrs, 0, common_attrs_sz);
>> +               common_attrs.log_buf = ptr_to_u64(log_buf);
>> +               common_attrs.log_size = OPTS_GET(opts, log_size, 0);
>> +               common_attrs.log_level = OPTS_GET(opts, log_level, 0);
>> +               fd = sys_bpf_ext_fd(BPF_MAP_CREATE, &attr, attr_sz, &common_attrs, common_attrs_sz);
>> +               OPTS_SET(opts, log_true_size, common_attrs.log_true_size);
>> +       } else {
>> +               fd = sys_bpf_fd(BPF_MAP_CREATE, &attr, attr_sz);
>> +       }
>>         return libbpf_err_errno(fd);
>>  }
>>
>> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
>> index e983a3e40d612..77d475e7274a0 100644
>> --- a/tools/lib/bpf/bpf.h
>> +++ b/tools/lib/bpf/bpf.h
>> @@ -57,16 +57,21 @@ struct bpf_map_create_opts {
>>
>>         const void *excl_prog_hash;
>>         __u32 excl_prog_hash_size;
>> +
>> +       const char *log_buf;
>> +       __u32 log_size;
>> +       __u32 log_level;
>> +       __u32 log_true_size;
>
> I'm thinking that maybe we should have a separate struct that will
> have these 4 fields, and pass a pointer to it. That way
> bpf_map_create_opts can still be passed as const pointer, but libbpf
> will still be able to write out log_true_size without violating
> constness
>
> and then we can reuse the same type (struct bpf_log? struct
> bpf_log_buf? struct bpf_log_info? not sure, let's bikeshed) across
> different commands that support passing log info through
> bpf_common_attrs
>

Sure, that makes sense.

I add a new 'struct bpf_log_attr' to encapsulate these four fields, and
it works well in my local testing.

This also keeps bpf_map_create_opts const-safe while making it easier to
reuse the same structure for other commands using bpf_common_attrs.

Thanks,
Leon

[...]

  reply	other threads:[~2025-10-09  5:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-02 15:48 [RFC PATCH bpf-next v3 00/10] bpf: Extend bpf syscall with common attributes support Leon Hwang
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 01/10] " Leon Hwang
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 02/10] libbpf: Add support for extended bpf syscall Leon Hwang
2025-10-06 23:08   ` Andrii Nakryiko
2025-10-09  5:15     ` Leon Hwang
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 03/10] bpf: Refactor reporting log_true_size for prog_load Leon Hwang
2025-10-02 18:34   ` Alexei Starovoitov
2025-10-03  2:06     ` Leon Hwang
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 04/10] bpf: Add common attr support " Leon Hwang
2025-10-02 23:51   ` Alexei Starovoitov
2025-10-03  2:25     ` Leon Hwang
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 05/10] bpf: Refactor reporting btf_log_true_size for btf_load Leon Hwang
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 06/10] bpf: Add common attr support " Leon Hwang
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 07/10] bpf: Add warnings for internal bugs in map_create Leon Hwang
2025-10-03  0:06   ` Alexei Starovoitov
2025-10-03  2:31     ` Leon Hwang
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 08/10] bpf: Add common attr support for map_create Leon Hwang
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 09/10] libbpf: " Leon Hwang
2025-10-06 23:08   ` Andrii Nakryiko
2025-10-09  5:35     ` Leon Hwang [this message]
2025-10-02 15:48 ` [RFC PATCH bpf-next v3 10/10] selftests/bpf: Add cases to test map create failure log Leon Hwang
2025-10-03  6:38 ` [syzbot ci] Re: bpf: Extend bpf syscall with common attributes support syzbot ci
2025-10-03  6:44   ` Leon Hwang

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=16e155c2-294a-48b6-9339-75aa4edf8048@linux.dev \
    --to=leon.hwang@linux.dev \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.