Thank you for the review. The batch implementation is patch 1 of the same series: https://lore.kernel.org/r/[email protected]
Its dump_map_batch() calls bpf_map_lookup_batch(), starts with up to 256 entries and grows the buffer on ENOSPC. Patch 2 tests that implementation. The range described in the review appears to include the separate ring buffer patch instead of this batch implementation. The 255/256/257 cases therefore do straddle an implemented boundary. Their assertions compare complete observable key/value output and do not require a particular internal traversal order. I also built and tested the v1 batch series independently and confirmed the batch syscalls. The updated series is here: https://lore.kernel.org/r/[email protected] It also addresses the separate JSON error-reporting and comment-style feedback. Fatal batch diagnostics now go to stderr. Fault injection checked initial EFAULT/ENOMEM and post-progress EIO/EINVAL in compact and pretty JSON, both with and without recursive dumping: documents remained complete and contained only expected map entries, with a nonzero status. Unsupported-command fallback and ENOSPC growth retained all 1,025 entries. Thanks, Tianyi
