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

[Alexei Starovoitov]

On Mon, Apr 19, 2021 at 6:52 AM Pedro Tammela <pctammela@xxxxxxxxx> wrote:
>
> Em dom., 18 de abr. de 2021 às 19:56, Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> escreveu:
> >
> > On Sun, Apr 18, 2021 at 1:03 PM Pedro Tammela <pctammela@xxxxxxxxx> 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@xxxxxxxxxx/
> > >
> > > Signed-off-by: Pedro Tammela <pctammela@xxxxxxxxxxxx>
> > > ---
> > >  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.