netdev - Re: [bpf-next 2/2] libbpf: Add pathname

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: <CAEf4Bza_449Ku65rLFG391aS6_ec-rt-sWbspveZ_nhBKn2j8w@mail.gmail.com>
Date:   Wed, 21 Sep 2022 17:42:53 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     sdf@...gle.com
Cc:     Wang Yufen <wangyufen@...wei.com>, andrii@...nel.org,
        ast@...nel.org, daniel@...earbox.net, martin.lau@...ux.dev,
        song@...nel.org, yhs@...com, john.fastabend@...il.com,
        kpsingh@...nel.org, haoluo@...gle.com, jolsa@...nel.org,
        paul.walmsley@...ive.com, palmer@...belt.com,
        aou@...s.berkeley.edu, davem@...emloft.net, kuba@...nel.org,
        hawk@...nel.org, nathan@...nel.org, ndesaulniers@...gle.com,
        trix@...hat.com, bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [bpf-next 2/2] libbpf: Add pathname_concat() helper

On Fri, Sep 9, 2022 at 10:16 AM <sdf@...gle.com> wrote:
>
> On 09/09, Wang Yufen wrote:
> > Move snprintf and len check to common helper pathname_concat() to make the
> > code simpler.
>
> > Signed-off-by: Wang Yufen <wangyufen@...wei.com>
> > ---
> >   tools/lib/bpf/libbpf.c | 74
> > ++++++++++++++++++--------------------------------
> >   1 file changed, 27 insertions(+), 47 deletions(-)
>
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 5854b92..238a03e 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -2096,20 +2096,31 @@ static bool get_map_field_int(const char
> > *map_name, const struct btf *btf,
> >       return true;
> >   }
>
> > -static int build_map_pin_path(struct bpf_map *map, const char *path)
> > +static int pathname_concat(const char *path, const char *name, char *buf)
> >   {
> > -     char buf[PATH_MAX];
> >       int len;
>
> > -     if (!path)
> > -             path = "/sys/fs/bpf";
> > -
> > -     len = snprintf(buf, PATH_MAX, "%s/%s", path, bpf_map__name(map));
> > +     len = snprintf(buf, PATH_MAX, "%s/%s", path, name);
> >       if (len < 0)
> >               return -EINVAL;
> >       else if (len >= PATH_MAX)
> >               return -ENAMETOOLONG;
>
> > +     return 0;
> > +}
> > +
> > +static int build_map_pin_path(struct bpf_map *map, const char *path)
> > +{
> > +     char buf[PATH_MAX];
> > +     int err;
> > +
> > +     if (!path)
> > +             path = "/sys/fs/bpf";
> > +
> > +     err = pathname_concat(path, bpf_map__name(map), buf);
> > +     if (err)
> > +             return err;
> > +
> >       return bpf_map__set_pin_path(map, buf);
> >   }
>
> > @@ -7959,17 +7970,8 @@ int bpf_object__pin_maps(struct bpf_object *obj,
> > const char *path)
> >                       continue;
>
> >               if (path) {
> > -                     int len;
> > -
> > -                     len = snprintf(buf, PATH_MAX, "%s/%s", path,
> > -                                    bpf_map__name(map));
> > -                     if (len < 0) {
> > -                             err = -EINVAL;
> > -                             goto err_unpin_maps;
> > -                     } else if (len >= PATH_MAX) {
> > -                             err = -ENAMETOOLONG;
>
> [..]
>
> > +                     if (pathname_concat(path, bpf_map__name(map), buf))
> >                               goto err_unpin_maps;
> > -                     }
>
> You're breaking error reporting here and in a bunch of other places.
> Should be:
>
> err = pathname_concat();
> if (err)
>         goto err_unpin_maps;
>
> I have the same attitude towards this patch as the first one in the
> series: not worth it. Nothing is currently broken, the code as is relatively
> readable, this version is not much simpler, it just looks slightly different
> taste-wise..
>

It's a minor improvement, IMO, so I don't mind it (5 repetitions of
annoying error case handling seems worth streamlining). But selftests
just for this seems like an overkill.

> How about this: if you really want to push this kind of cleanup, send
> selftests that exercise all these error cases? :-)
>
>

[...]