The ship has probably sailed on this one, but it seems like ENOSPC makes more sense than E2BIG. Any chance of changing it so that poor ebpf library maintainers in the future don't have to wonder how their argument list got too big?
net-next/master:kernel/bpf/hashtab.c=static int htab_map_update_elem(struct bpf_map *map, void *key, void *value, -- net-next/master:kernel/bpf/hashtab.c- net-next/master:kernel/bpf/hashtab.c- if (!l_old && unlikely(htab->count >= map->max_entries)) { net-next/master:kernel/bpf/hashtab.c- /* if elem with this 'key' doesn't exist and we've reached net-next/master:kernel/bpf/hashtab.c- * max_entries limit, fail insertion of new elem net-next/master:kernel/bpf/hashtab.c- */ net-next/master:kernel/bpf/hashtab.c: ret = -E2BIG; net-next/master:kernel/bpf/hashtab.c- goto err; net-next/master:kernel/bpf/hashtab.c- } net-next/master:kernel/bpf/hashtab.c- net-next/master:kernel/bpf/hashtab.c- if (l_old && map_flags == BPF_NOEXIST) { net-next/master:kernel/bpf/hashtab.c- /* elem already exists */ -- Alex Gartrell <agartr...@fb.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html