From: Quentin Monnet <qmo@kernel.org>
To: Maxim Skokov <skokovmaksimevg@gmail.com>,
bpf@vger.kernel.org, Tianyi Chen <hi@tychen.cc>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, memxor@gmail.com, martin.lau@linux.dev,
song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org,
emil@etsalapatis.com, ihor.solodrai@linux.dev, kuba@kernel.org,
shuah@kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 1/2] bpftool: Fail map dump for maps that can't be iterated
Date: Fri, 25 Sep 2026 20:24:44 +0100 [thread overview]
Message-ID: <661699fb-456c-4e68-85df-94cb829b2204@kernel.org> (raw)
In-Reply-To: <20260925162031.27259-2-skokovmaksimevg@gmail.com>
2026-09-25 19:20 UTC+0300 ~ Maxim Skokov <skokovmaksimevg@gmail.com>
> "bpftool map dump" walks the map with bpf_map_get_next_key() and treats
> ENOENT as the end of the map. Map types that can't be iterated fail that
> call on the very first key: local storage and ringbuf with ENOTSUPP,
> bloom filter and arena with EOPNOTSUPP, queue and stack with EINVAL.
> bpftool then ends the walk without a word and prints what it prints for
> an empty map, "[]" with BTF or "Found 0 elements" without, and only the
> exit status tells that the map was not read. On a socket storage map
> that holds storage for a socket:
>
> # bpftool map dump pinned /sys/fs/bpf/sk_storage
> []
>
> Ask for the first key before printing anything, and when that fails with
> anything but ENOENT, fail with the map type and the error instead of a
> dump:
>
> # bpftool map dump pinned /sys/fs/bpf/sk_storage
> Error: can't dump sk_storage map: Unknown error 524
> # bpftool -j map dump pinned /sys/fs/bpf/sk_storage
> {"error":"can't dump sk_storage map: Unknown error 524"}
>
> An error later in the walk is now reported too, as "bpftool map getnext"
> reports it, and the element count is printed only after a complete walk.
>
> Assisted-by: LLM
> Signed-off-by: Maxim Skokov <skokovmaksimevg@gmail.com>
> ---
> tools/bpf/bpftool/map.c | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
> index 20d59eab09..626882f207 100644
> --- a/tools/bpf/bpftool/map.c
> +++ b/tools/bpf/bpftool/map.c
> @@ -856,6 +856,25 @@ map_dump(int fd, struct bpf_map_info *info, json_writer_t *wtr,
> }
> }
>
> + /*
> + * Map types that can't be iterated fail on the very first key. Say so
> + * before printing anything, so that the output isn't an empty dump.
> + */
Or simply:
/* Fail early to avoid an empty dump if map type cannot be iterated */
But that's a minor nit, the patch looks good to me, thank you!
Acked-by: Quentin Monnet <qmo@kernel.org>
Looks like you need to address Sashiko's findings on patch 2, though.
> + if (bpf_map_get_next_key(fd, NULL, key) && errno != ENOENT) {
> + const char *map_type_str;
> + int saved_errno = errno;
> +
> + map_type_str = libbpf_bpf_map_type_str(info->type);
> + if (map_type_str)
> + p_err("can't dump %s map: %s", map_type_str,
> + strerror(saved_errno));
> + else
> + p_err("can't dump map of type %u: %s", info->type,
> + strerror(saved_errno));
> + err = -1;
> + goto exit_free;
> + }
Tianyi, note that this conflicts with your series ("bpftool: Add
recursive map dumping"), one of you will have to rebase.
> +
> if (wtr) {
> err = get_map_kv_btf(info, &btf);
> if (err) {
> @@ -883,8 +902,11 @@ map_dump(int fd, struct bpf_map_info *info, json_writer_t *wtr,
> while (true) {
> err = bpf_map_get_next_key(fd, prev_key, key);
> if (err) {
> - if (errno == ENOENT)
> + if (errno == ENOENT) {
> err = 0;
> + break;
> + }
> + p_err("can't get next key: %s", strerror(errno));
> break;
> }
> if (!dump_map_elem(fd, key, value, info, btf, wtr,
> @@ -897,7 +919,7 @@ map_dump(int fd, struct bpf_map_info *info, json_writer_t *wtr,
> jsonw_end_array(wtr); /* elements */
> if (show_header)
> jsonw_end_object(wtr); /* map object */
> - } else {
> + } else if (!err) {
> printf("Found %u element%s\n", num_elems,
> num_elems != 1 ? "s" : "");
> }
next prev parent reply other threads:[~2026-09-25 19:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 16:20 [PATCH bpf-next v2 0/2] bpftool: Fail map dump for maps that can't be iterated Maxim Skokov
2026-09-25 16:20 ` [PATCH bpf-next v2 1/2] " Maxim Skokov
2026-09-25 19:24 ` Quentin Monnet [this message]
2026-09-26 1:44 ` Tianyi Chen
2026-09-25 16:20 ` [PATCH bpf-next v2 2/2] selftests/bpf: Check that bpftool map dump fails for socket storage Maxim Skokov
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=661699fb-456c-4e68-85df-94cb829b2204@kernel.org \
--to=qmo@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=hi@tychen.cc \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=shuah@kernel.org \
--cc=skokovmaksimevg@gmail.com \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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