> diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
> index 684a8fb72414..c0505f504967 100644
> --- a/tools/bpf/bpftool/map.c
> +++ b/tools/bpf/bpftool/map.c
[ ... ]
> @@ -826,12 +827,44 @@ static void free_map_kv_btf(struct btf *btf)
> btf__free(btf);
> }
>
> +struct map_dump_ctx {
> + struct hashmap *seen;
> + __u32 *pending_ids;
> + size_t pending_cnt;
> +};
> +
> +static int collect_inner_map(struct map_dump_ctx *ctx, __u32 id)
> +{
> + __u32 *ids;
> + int err;
> +
> + if (hashmap__find(ctx->seen, id, NULL))
> + return 0;
> +
> + ids = libbpf_reallocarray(ctx->pending_ids, ctx->pending_cnt + 1,
> + sizeof(*ids));
> + if (!ids) {
> + p_err("mem alloc failed");
> + return -1;
> + }
> + ctx->pending_ids = ids;
This isn't a bug, but since libbpf_internal.h is already being pulled
in here, would libbpf_ensure_mem() (with a cap field in struct
map_dump_ctx) be a better fit than reallocating by one element per
discovered inner map?
The pending-id array grows by exactly one element for every newly
discovered inner map, so a map-of-maps with N distinct inner maps
performs N reallocations. libbpf_ensure_mem() is designed for this
pattern and grows the buffer geometrically, keeping the growth
amortised.
---
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/34560347455
