netdev - Re: [PATCH] bpf: fix errno code for unsupported batch ops

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAADnVQ+KhDOZGn9jAhfWbOOTTFZB0JL1i046y5XEuMzcuQQ8oA@mail.gmail.com>
Date:   Mon, 19 Apr 2021 07:32:50 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Pedro Tammela <pctammela@...il.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
        Pedro Tammela <pctammela@...atatu.com>
Subject: Re: [PATCH] bpf: fix errno code for unsupported batch ops

On Mon, Apr 19, 2021 at 6:52 AM Pedro Tammela <pctammela@...il.com> wrote:
>
> Em dom., 18 de abr. de 2021 às 19:56, Alexei Starovoitov
> <alexei.starovoitov@...il.com> escreveu:
> >
> > On Sun, Apr 18, 2021 at 1:03 PM Pedro Tammela <pctammela@...il.com> wrote:
> > >
> > > ENOTSUPP is not a valid userland errno[1], which is annoying for
> > > userland applications that implement a fallback to iterative, report
> > > errors via 'strerror()' or both.
> > >
> > > The batched ops return this errno whenever an operation
> > > is not implemented for kernels that implement batched ops.
> > >
> > > In older kernels, pre batched ops, it returns EINVAL as the arguments
> > > are not supported in the syscall.
> > >
> > > [1] https://lore.kernel.org/netdev/20200511165319.2251678-1-kuba@kernel.org/
> > >
> > > Signed-off-by: Pedro Tammela <pctammela@...atatu.com>
> > > ---
> > >  kernel/bpf/syscall.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> > > index fd495190115e..88fe19c0aeb1 100644
> > > --- a/kernel/bpf/syscall.c
> > > +++ b/kernel/bpf/syscall.c
> > > @@ -3961,7 +3961,7 @@ static int bpf_task_fd_query(const union bpf_attr *attr,
> > >  #define BPF_DO_BATCH(fn)                       \
> > >         do {                                    \
> > >                 if (!fn) {                      \
> > > -                       err = -ENOTSUPP;        \
> > > +                       err = -EOPNOTSUPP;      \
> >
> > $ git grep EOPNOTSUPP kernel/bpf/|wc -l
> > 11
> > $ git grep ENOTSUPP kernel/bpf/|wc -l
> > 51
> >
> > For new code EOPNOTSUPP is better, but I don't think changing all 51 case
> > is a good idea. Something might depend on it already.
>
> OK, makes sense.
>
> Perhaps, handle this errno in 'libbpf_strerror()'?

That's a good idea.

> So language
> bindings don't get lost when dealing with this errno.

I'm not sure what you mean by "language bindings".
In general, strerror is not that useful. The kernel aliases
multiple conditions into the same error code. The error string
is too generic in practice to be useful.