bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
	bpf@vger.kernel.org
Cc: alan.maguire@oracle.com, Quentin Monnet <qmo@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [RFC bpf-next 1/2] bpftool: Print map ID upon creation and support JSON output
Date: Wed, 29 Oct 2025 10:56:23 -0700	[thread overview]
Message-ID: <7a6be149-9e04-444e-a433-49450385d6a0@linux.dev> (raw)
In-Reply-To: <cc32d3db-60ef-4046-8988-289cd0cc8c26@oracle.com>



On 10/29/25 9:05 AM, Harshit Mogalapalli wrote:
> Hi Yonghong,
>
>
> On 29/10/25 07:44, Yonghong Song wrote:
>>
>>
>> On 10/28/25 5:57 AM, Harshit Mogalapalli wrote:
>>> It is useful to print map ID on successful creation.
>>>
>>> JSON case:
>>> $ ./bpftool -j map create /sys/fs/bpf/test_map4 type hash key 4 
>>> value 8 entries 128 name map4
>>> {"id":12}
>>>
>>> Generic case:
>>> $ ./bpftool  map create /sys/fs/bpf/test_map5 type hash key 4 value 
>>> 8 entries 128 name map5
>>> Map successfully created with ID: 15
>>>
>>> Bpftool Issue: https://github.com/libbpf/bpftool/issues/121
>>> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
>>> ---
>>>   tools/bpf/bpftool/map.c | 24 ++++++++++++++++++++----
>>>   1 file changed, 20 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
>>> index c9de44a45778..b6580f25361d 100644
>>> --- a/tools/bpf/bpftool/map.c
>>> +++ b/tools/bpf/bpftool/map.c
>>> @@ -1251,6 +1251,8 @@ static int do_create(int argc, char **argv)
>>>       LIBBPF_OPTS(bpf_map_create_opts, attr);
>>>       enum bpf_map_type map_type = BPF_MAP_TYPE_UNSPEC;
>>>       __u32 key_size = 0, value_size = 0, max_entries = 0;
>>> +    struct bpf_map_info map_info = {};
>>> +    __u32 map_info_len = sizeof(map_info);
>>>       const char *map_name = NULL;
>>>       const char *pinfile;
>>>       int err = -1, fd;
>>> @@ -1353,13 +1355,27 @@ static int do_create(int argc, char **argv)
>>>       }
>>>       err = do_pin_fd(fd, pinfile);
>>> -    close(fd);
>>> -    if (err)
>>> +    if (err) {
>>> +        close(fd);
>>
>> I think you can remove close(fd) here,
>>
>>>           goto exit;
>>> +    }
>>> -    if (json_output)
>>> -        jsonw_null(json_wtr);
>>> +    err = bpf_obj_get_info_by_fd(fd, &map_info, &map_info_len);
>>> +    if (err) {
>>> +        p_err("Failed to fetch map info: %s\n", strerror(errno));
>>> +        close(fd);
>>
>> and here
>>
>>> +        goto exit;
>>> +    }
>>> +    close(fd);
>>
>> and here,
>>
>>> +
>>> +    if (json_output) {
>>> +        jsonw_start_object(json_wtr);
>>> +        jsonw_int_field(json_wtr, "id", map_info.id);
>>> +        jsonw_end_object(json_wtr);
>>> +    } else {
>>> +        printf("Map successfully created with ID: %u\n", map_info.id);
>>> +    }
>>>   exit:
>>
>> and put close(fd) here.
>
> I think we need one more close_fd: label and then put a close(fd); 
> here. As there are other gotos to exit earlier in this function when 
> fd is uninitialized, which can the error like:
>
> map.c: In function ‘do_create’:
> map.c:1375:9: warning: ‘fd’ may be used uninitialized 
> [-Wmaybe-uninitialized]
>  1375 |         close(fd);
>       |         ^~~~~~~~~
> map.c:1258:23: note: ‘fd’ was declared here
>  1258 |         int err = -1, fd;
>       |                       ^~
>
>
>
> So, maybe we could do something like this:
>
>         err = do_pin_fd(fd, pinfile);
> -       close(fd);
>         if (err)
> -               goto exit;
> +               goto close_fd;
>
> -       if (json_output)
> -               jsonw_null(json_wtr);
> +       err = bpf_obj_get_info_by_fd(fd, &map_info, &map_info_len);
> +       if (err) {
> +               p_err("Failed to fetch map info: %s\n", strerror(errno));
> +               goto close_fd;
> +       }
>
> +       if (json_output) {
> +               jsonw_start_object(json_wtr);
> +               jsonw_int_field(json_wtr, "id", map_info.id);
> +               jsonw_end_object(json_wtr);
> +       } else {
> +               printf("Map successfully created with ID: %u\n", 
> map_info.id);
> +       }
> +close_fd:
> +       close(fd);
>  exit:
>         if (attr.inner_map_fd > 0)
>                 close(attr.inner_map_fd);
>
> I can prepare a v2 with this change, but wouldn't it be simpler to add a
> direct close(fd); on the few error paths instead of introducing an
> additional label for close(fd);?

The above change LGTM. Thanks!

>
> Thoughts/Suggestions ?
>
> Thanks,
> Harshit
>
>>
>>>       if (attr.inner_map_fd > 0)
>>>           close(attr.inner_map_fd);
>>
>>
>
>


  reply	other threads:[~2025-10-29 17:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28 12:57 [RFC bpf-next 0/2] Print map ID on successful creation Harshit Mogalapalli
2025-10-28 12:57 ` [RFC bpf-next 1/2] bpftool: Print map ID upon creation and support JSON output Harshit Mogalapalli
2025-10-29  2:14   ` Yonghong Song
2025-10-29  8:48     ` Harshit Mogalapalli
2025-10-29 16:05     ` Harshit Mogalapalli
2025-10-29 17:56       ` Yonghong Song [this message]
2025-10-28 12:57 ` [RFC bpf-next 2/2] selftests/bpf: Add test for bpftool map ID printing Harshit Mogalapalli

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=7a6be149-9e04-444e-a433-49450385d6a0@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=harshit.m.mogalapalli@oracle.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=qmo@kernel.org \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@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).