[PATCH bpf-next 0/2] bpftool: Don't report an empty map when key iteration fails

[PATCH bpf-next 0/2] bpftool: Don't report an empty map when key iteration fails

[Maxim Skokov]

"bpftool map dump" stops at the first bpf_map_get_next_key() error and only
treats ENOENT as the end of the map. Any other error gives an empty dump
with no message, only a non-zero exit status. Local storage maps always
fail that way, so a socket storage map holding elements dumps as "[]".

Patch 1 reports the error like "bpftool map getnext" already does, with a
hint when the map type can't be iterated. Patch 2 adds a test_progs case.

The new test fails without patch 1 and passes with it; the other bpftool_*
selftests pass. Tested on x86_64 under a bpf-next kernel with KASAN and
lockdep, and through BPF CI (x86_64, aarch64, s390x).

Maxim Skokov (2):
  bpftool: Don't report an empty map when key iteration fails
  selftests/bpf: Check that bpftool reports a map it can't dump

 tools/bpf/bpftool/map.c                       | 11 ++-
 .../bpf/prog_tests/bpftool_map_dump.c         | 76 +++++++++++++++++++
 2 files changed, 85 insertions(+), 2 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c


base-commit: 4f3a5eae895b9995e93425a75235d8f1f3268caa
-- 
2.47.3

[PATCH bpf-next 1/2] bpftool: Don't report an empty map when key iteration fails

[Maxim Skokov]

map_dump() walks the map with bpf_map_get_next_key() and treats ENOENT
as the end of the map. Any other error ends the walk as well, but
silently: bpftool prints an empty dump, "[]" with BTF or "Found 0
elements" without, and only the exit status tells that the map was not
read at all.

This is what every local storage map (sk, inode, task and cgrp storage)
gets, since their map_get_next_key returns -ENOTSUPP. On a
BPF_MAP_TYPE_SK_STORAGE map holding storage for five TCP sockets:

  # bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_reverse_sk_v2
  []
  # echo $?
  244

"bpftool map getnext" on the same map already reports the failure.
Report it the same way from map dump, with a hint when the map type
does not support iteration, and print the element count only after the
whole map was walked:

  # bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_reverse_sk_v2
  []
  Error: can't get next key: Unknown error 524 -- map type does not support iteration

In JSON mode the error is emitted as an {"error": ...} object, as for
the other bpftool commands.

Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
Signed-off-by: Maxim Skokov <skokovmaksimevg@gmail.com>
Assisted-by: LLM
---
 tools/bpf/bpftool/map.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 20d59eab09..00e49ae05c 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -883,8 +883,15 @@ 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)
+			int saved_errno = errno;
+
+			if (saved_errno == ENOENT) {
 				err = 0;
+				break;
+			}
+			p_err("can't get next key: %s%s", strerror(saved_errno),
+			      saved_errno == 524 /* ENOTSUPP */ ?
+			      " -- map type does not support iteration" : "");
 			break;
 		}
 		if (!dump_map_elem(fd, key, value, info, btf, wtr,
@@ -897,7 +904,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" : "");
 	}
-- 
2.47.3

Re: [PATCH bpf-next 1/2] bpftool: Don't report an empty map when key iteration fails

[Alexei Starovoitov]

On Thu, Sep 24, 2026 at 07:07 PM Maxim Skokov <skokovmaksimevg@gmail.com> wrote:
> This is what every local storage map (sk, inode, task and cgrp storage)
> gets, since their map_get_next_key returns -ENOTSUPP. On a
> BPF_MAP_TYPE_SK_STORAGE map holding storage for five TCP sockets:
>
>   # bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_reverse_sk_v2
>   []
>   # echo $?
>   244

cilium_lb4_reverse_sk is an LRU hash in cilium. It's not sk_storage
and bpftool dumps it just fine.
So where did this output come from?

[...]

> Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")

That's not a fix. The exit status was non-zero before and it's the
same after. Drop the Fixes tag.

[...]

> +			p_err("can't get next key: %s%s", strerror(saved_errno),
> +			      saved_errno == 524 /* ENOTSUPP */ ?
> +			      " -- map type does not support iteration" : "");

Local storage and ringbuf return ENOTSUPP.
Bloom filter and arena return EOPNOTSUPP. Queue and stack return EINVAL.
None of them can be iterated. The hint is printed for the first two only.

[...]

> -	} else {
> +	} else if (!err) {
>  		printf("Found %u element%s\n", num_elems,
>  		       num_elems != 1 ? "s" : "");

The subject says "Don't report an empty map", but when the map has BTF
the elements array is opened before the loop and closed after it,
so stdout is still "[]". Only the line on stderr is new.
With -j the error object is printed inside that array:
[{"error":"can't get next key: ..."}]

pw-bot: cr

Re: [PATCH bpf-next 1/2] bpftool: Don't report an empty map when key iteration fails

[Maxim Skokov]

On Thu, Sep 24, 2026 at 04:24 PM Alexei Starovoitov wrote:
> cilium_lb4_reverse_sk is an LRU hash in cilium. It's not sk_storage
> and bpftool dumps it just fine.
> So where did this output come from?

That's cilium_lb4_reverse_sk_v2, a BPF_MAP_TYPE_SK_STORAGE map from an
unmerged Cilium change (cilium/cilium#44767) I was testing, not the
upstream LRU map. Bad example, v2 will use a plain socket storage map.

> That's not a fix. The exit status was non-zero before and it's the
> same after. Drop the Fixes tag.

Will do.

> Local storage and ringbuf return ENOTSUPP.
> Bloom filter and arena return EOPNOTSUPP. Queue and stack return EINVAL.
> None of them can be iterated. The hint is printed for the first two only.

> The subject says "Don't report an empty map", but when the map has BTF
> the elements array is opened before the loop and closed after it,
> so stdout is still "[]". Only the line on stderr is new.

Right on both. In v2 map_dump() asks for the first key before printing
the header or opening the array, and on anything but ENOENT fails with
"can't dump <map type> map: <error>". Nothing goes to stdout then, -j
gives only the error object, and no errno guessing is needed.

Re: [PATCH bpf-next 1/2] bpftool: Don't report an empty map when key iteration fails

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

> bpftool: Don't report an empty map when key iteration fails

The subject says "Don't report an empty map", but when the map has BTF,
the elements array is opened before the loop and closed after it, so stdout
is still "[]". Only the line on stderr is new.

With -j the error object is printed inside that array:
[{"error":"can't get next key: ..."}]. Does the actual behavior match the
subject line?

>     map_dump() walks the map with bpf_map_get_next_key() and treats ENOENT
>     as the end of the map. Any other error ends the walk as well, but
>     silently: bpftool prints an empty dump, "[]" with BTF or "Found 0
>     elements" without, and only the exit status tells that the map was not
>     read at all.
>
>     This is what every local storage map (sk, inode, task and cgrp storage)
>     gets, since their map_get_next_key returns -ENOTSUPP. On a
>     BPF_MAP_TYPE_SK_STORAGE map holding storage for five TCP sockets:
>
>       # bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_reverse_sk_v2
>       []
>       # echo $?
>       244

The commit message uses "/sys/fs/bpf/tc/globals/cilium_lb4_reverse_sk_v2"
as an example. However, cilium_lb4_reverse_sk is an LRU hash in Cilium,
not sk_storage, and bpftool dumps it just fine. Where did this output come
from?

[ ... ]

>     Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")

The exit status was non-zero before and remains non-zero after. Should the
Fixes tag be dropped since this is not a fix?

> diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
> index 20d59eab09a1..00e49ae05c08 100644
> --- a/tools/bpf/bpftool/map.c
> +++ b/tools/bpf/bpftool/map.c
> @@ -883,8 +883,15 @@ 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)
> +			int saved_errno = errno;
> +
> +			if (saved_errno == ENOENT) {
>  				err = 0;
> +				break;
> +			}
> +			p_err("can't get next key: %s%s", strerror(saved_errno),
> +			      saved_errno == 524 /* ENOTSUPP */ ?
> +			      " -- map type does not support iteration" : "");

The hint "map type does not support iteration" is only printed for
ENOTSUPP (524). However, other non-iterable map types return different
errors:

- Local storage and ringbuf return ENOTSUPP
- Bloom filter and arena return EOPNOTSUPP
- Queue and stack return EINVAL

Should the hint cover all non-iterable map types, not just those that
return ENOTSUPP?

>  			break;
>  		}
>  		if (!dump_map_elem(fd, key, value, info, btf, wtr,

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/36027992199

Re: [PATCH bpf-next 1/2] bpftool: Don't report an empty map when key iteration fails

[Maxim Skokov]

These are the points from Alexei's review, answered here:
https://lore.kernel.org/bpf/20260924163536.507053-1-skokovmaksimevg@gmail.com/

All four are addressed in v2, which goes out once 24 hours have passed
since v1.

[PATCH bpf-next 2/2] selftests/bpf: Check that bpftool reports a map it can't dump

[Maxim Skokov]

Socket storage can't be iterated from user space, so "bpftool map dump"
used to print an empty map and exit with an error status, without saying
why. Create a BPF_MAP_TYPE_SK_STORAGE map, attach storage to a socket,
pin it, and check that both JSON and plain dumps fail with a message.

Signed-off-by: Maxim Skokov <skokovmaksimevg@gmail.com>
Assisted-by: LLM
---
 .../bpf/prog_tests/bpftool_map_dump.c         | 76 +++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c

diff --git a/tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c b/tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c
new file mode 100644
index 0000000000..56283e3f1e
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <sys/socket.h>
+#include <unistd.h>
+#include <bpf/btf.h>
+#include <test_progs.h>
+#include "bpftool_helpers.h"
+
+#define PIN_PATH	"/sys/fs/bpf/test_bpftool_map_dump_sk_storage"
+
+/* A socket storage map with a single element, keyed on a socket we own. */
+static int create_sk_storage_map(void)
+{
+	LIBBPF_OPTS(bpf_map_create_opts, opts,
+		    .map_flags = BPF_F_NO_PREALLOC);
+	struct btf *btf;
+	int int_id, fd = -1;
+
+	btf = btf__new_empty();
+	if (!ASSERT_OK_PTR(btf, "btf__new_empty"))
+		return -1;
+
+	int_id = btf__add_int(btf, "int", 4, BTF_INT_SIGNED);
+	if (!ASSERT_GT(int_id, 0, "btf__add_int"))
+		goto out;
+	if (!ASSERT_OK(btf__load_into_kernel(btf), "btf__load_into_kernel"))
+		goto out;
+
+	opts.btf_fd = btf__fd(btf);
+	opts.btf_key_type_id = int_id;
+	opts.btf_value_type_id = int_id;
+	fd = bpf_map_create(BPF_MAP_TYPE_SK_STORAGE, "sk_storage", sizeof(int),
+			    sizeof(int), 0, &opts);
+	ASSERT_OK_FD(fd, "bpf_map_create");
+out:
+	btf__free(btf);
+	return fd;
+}
+
+void test_bpftool_map_dump(void)
+{
+	int map_fd, sk_fd = -1, value = 42, ret;
+	char output[1024];
+
+	map_fd = create_sk_storage_map();
+	if (map_fd < 0)
+		return;
+
+	sk_fd = socket(AF_INET, SOCK_STREAM, 0);
+	if (!ASSERT_OK_FD(sk_fd, "socket"))
+		goto out;
+	if (!ASSERT_OK(bpf_map_update_elem(map_fd, &sk_fd, &value, BPF_NOEXIST),
+		       "add socket storage"))
+		goto out;
+	if (!ASSERT_OK(bpf_obj_pin(map_fd, PIN_PATH), "pin map"))
+		goto out;
+
+	/* Socket storage can not be iterated, so the dump must fail loudly
+	 * rather than print an empty map that holds an element.
+	 */
+	ret = get_bpftool_command_output("-j map dump pinned " PIN_PATH,
+					 output, sizeof(output));
+	ASSERT_NEQ(ret, 0, "json dump fails");
+	ASSERT_HAS_SUBSTR(output, "\"error\":", "json dump reports an error");
+
+	ret = get_bpftool_command_output("map dump pinned " PIN_PATH " 2>&1",
+					 output, sizeof(output));
+	ASSERT_NEQ(ret, 0, "plain dump fails");
+	ASSERT_HAS_SUBSTR(output, "does not support iteration",
+			  "plain dump explains why");
+
+	unlink(PIN_PATH);
+out:
+	if (sk_fd >= 0)
+		close(sk_fd);
+	close(map_fd);
+}
-- 
2.47.3

Re: [PATCH bpf-next 2/2] selftests/bpf: Check that bpftool reports a map it can't dump

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: uninitialized output buffer in test_bpftool_map_dump()
--

commit 18cf283c6b4e8fb98efa7b6286ae3efd8620915d
Author: Maxim Skokov <skokovmaksimevg@gmail.com>

selftests/bpf: Check that bpftool reports a map it can't dump

This commit adds a new test to verify that bpftool map dump correctly
reports an error when trying to dump a socket storage map, rather than
exiting silently. It creates a BPF_MAP_TYPE_SK_STORAGE map, attaches
storage to a socket, pins it, and runs bpftool to check the output.

> diff --git a/tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c b/tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c
> new file mode 100644
> index 0000000000000..56283e3f1e602
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c
[ ... ]
> +void test_bpftool_map_dump(void)
> +{
> +	int map_fd, sk_fd = -1, value = 42, ret;
> +	char output[1024];
[ ... ]
> +	/* Socket storage can not be iterated, so the dump must fail loudly
> +	 * rather than print an empty map that holds an element.
> +	 */
> +	ret = get_bpftool_command_output("-j map dump pinned " PIN_PATH,
> +					 output, sizeof(output));
> +	ASSERT_NEQ(ret, 0, "json dump fails");
> +	ASSERT_HAS_SUBSTR(output, "\"error\":", "json dump reports an error");

[Severity: Medium]
Could this result in an uninitialized memory read if get_bpftool_command_output()
fails early?

If bpftool path detection fails or popen() fails inside run_command(),
it returns 1 without writing anything to the buffer:

tools/testing/selftests/bpf/bpftool_helpers.c:run_command() {
	if (bpftool_path[0] == 0 && detect_bpftool_path(bpftool_path, sizeof(bpftool_path)))
		return 1;
	...
	f = popen(command, "r");
	if (!f)
		return 1;
	...
}

In this scenario, get_bpftool_command_output() will return 1, which satisfies
ASSERT_NEQ(ret, 0). The test will then pass the uninitialized output array to
ASSERT_HAS_SUBSTR(), which calls strstr() and may cause undefined behavior or
crashes.

Should output be zero-initialized, or should the test verify that output was
actually populated before checking its contents?

> +
> +	ret = get_bpftool_command_output("map dump pinned " PIN_PATH " 2>&1",
> +					 output, sizeof(output));
> +	ASSERT_NEQ(ret, 0, "plain dump fails");
> +	ASSERT_HAS_SUBSTR(output, "does not support iteration",
> +			  "plain dump explains why");
> +
> +	unlink(PIN_PATH);
> +out:
> +	if (sk_fd >= 0)
> +		close(sk_fd);
> +	close(map_fd);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924160732.485650-1-skokovmaksimevg@gmail.com?part=2

Re: [PATCH bpf-next 2/2] selftests/bpf: Check that bpftool reports a map it can't dump

[Maxim Skokov]

> Should output be zero-initialized, or should the test verify that output was
> actually populated before checking its contents?

Right. v2 clears the buffer before each bpftool run. That also covers a
second case: the plain run reused the buffer after the JSON run, whose
output holds the same message, so a plain run that failed to start would
have matched stale output.

Re: [PATCH bpf-next 2/2] selftests/bpf: Check that bpftool reports a map it can't dump

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

> diff --git a/tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c b/tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c
> new file mode 100644
> index 000000000000..56283e3f1e60
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/bpftool_map_dump.c

[ ... ]

> +	if (!ASSERT_OK(bpf_obj_pin(map_fd, PIN_PATH), "pin map"))
> +		goto out;
> +
> +	/* Socket storage can not be iterated, so the dump must fail loudly
> +	 * rather than print an empty map that holds an element.
> +	 */

Does this multi-line comment follow the BPF subsystem style? According to
bpf.md, multi-line comments should have the opening /* on its own line:

/*
 * Socket storage cannot be iterated, so the dump must fail loudly
 * rather than print an empty map that holds an element.
 */

Also, "can not" is typically written as "cannot" (one word).

> +	ret = get_bpftool_command_output("-j map dump pinned " PIN_PATH,
> +					 output, sizeof(output));

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/36027992199

Re: [PATCH bpf-next 2/2] selftests/bpf: Check that bpftool reports a map it can't dump

[Maxim Skokov]

> Does this multi-line comment follow the BPF subsystem style?

Fixed in v2: the opening /* is on its own line in both new multi-line
comments, the one in bpftool's map.c included. "can not" went away with
the reworded comment.