Why return E2BIG from bpf map update?

Why return E2BIG from bpf map update?

[Alex Gartrell]

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 <agartrell@fb.com>

Re: Why return E2BIG from bpf map update?

[Alexei Starovoitov]

On 7/20/15 3:15 PM, Alex Gartrell wrote:
> 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?

sorry, too late.
It's in tests and even document in bpf manpage:
"E2BIG - indicates that the number of elements in the map reached the
max_entries limit specified at map creation time."
I read E2BIG as "too big" and not as "argument list is too long" :)

Re: Why return E2BIG from bpf map update?

[Daniel Borkmann]

On 07/21/2015 12:24 AM, Alexei Starovoitov wrote:
> On 7/20/15 3:15 PM, Alex Gartrell wrote:
>> 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?
>
> sorry, too late.
> It's in tests and even document in bpf manpage:
> "E2BIG - indicates that the number of elements in the map reached the
> max_entries limit specified at map creation time."
> I read E2BIG as "too big" and not as "argument list is too long" :)

If some libraries do an strerror(3) on errno then it certainly sounds
a bit weird, "no space left on device" perhaps also a bit misleading.
The bpf(2) manpage was actually submitted/discussed longer time ago,
but I still didn't see it in Michael's tree yet, will ping him again.

Re: Why return E2BIG from bpf map update?

[Alex Gartrell]

On Tue, Jul 21, 2015 at 2:40 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 07/21/2015 12:24 AM, Alexei Starovoitov wrote:
>>
>> On 7/20/15 3:15 PM, Alex Gartrell wrote:
>>>
>>> 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?
>>
>>
>> sorry, too late.
>> It's in tests and even document in bpf manpage:
>> "E2BIG - indicates that the number of elements in the map reached the
>> max_entries limit specified at map creation time."
>> I read E2BIG as "too big" and not as "argument list is too long" :)
>
>
> If some libraries do an strerror(3) on errno then it certainly sounds
> a bit weird, "no space left on device" perhaps also a bit misleading.
> The bpf(2) manpage was actually submitted/discussed longer time ago,
> but I still didn't see it in Michael's tree yet, will ping him again.

I was just being whiny :)

The options really are
ENOMEM -- really should mean allocation failed
E2BIG -- really should mean argument list too big
ENOSPC -- really should mean that a physical device is full

I suppose there's also
EDQUOT -- Disk Quota Exceeded

And if you're really stretching
EXFULL - Exchange Full

but I've never seen either of the last two in my life.

So clearly this is all very subjective and people who complain about
it on mailing lists (me) are the worst.

The only complaint I'd have though is E2BIG actually does mean that
your bpf_attr argument is too big as well, so that part confused me
for a couple of minutes.  But, the EINVAL errno has similarly been
abused to death so I don't think it's that big of a deal.

/bikeshedding

-- 
Alex Gartrell <agartrell@fb.com>

Re: Why return E2BIG from bpf map update?

[Alexei Starovoitov]

On 7/21/15 3:13 AM, Alex Gartrell wrote:
> But, the EINVAL errno has similarly been
> abused to death

there was a thread few month ago trying to come up with
a generic solution for aliased error codes, but unfortunately
nothing concrete came out of it.
The one I liked sounded that the kernel may be able to extend
syscall interface to return a string together with errno,
but it's quite hard to do at present.
May be extensions to vdso data writable by kernel can
improve the situation.