Linux Kernel Selftest development
 help / color / mirror / Atom feed
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" : "");
>  	}


  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