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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

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