netdev - Re: [PATCH bpf-next v4 2/3] bpf: selftests: remove percpu macros from bpf

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKY_9u2uUm5Q+sLnizbpjcaoYBC_ih_qgvq-dDbcVQ-Fc+CfjA@mail.gmail.com>
Date:   Thu, 22 Apr 2021 16:27:25 -0300
From:   Pedro Tammela <pctammela@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        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>, Shuah Khan <shuah@...nel.org>,
        Pedro Tammela <pctammela@...atatu.com>,
        David Verbeiren <david.verbeiren@...sares.net>,
        Matthieu Baerts <matthieu.baerts@...sares.net>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v4 2/3] bpf: selftests: remove percpu macros from bpf_util.h

Em ter., 20 de abr. de 2021 às 13:42, Andrii Nakryiko
<andrii.nakryiko@...il.com> escreveu:
>
> On Tue, Apr 20, 2021 at 8:58 AM Daniel Borkmann <daniel@...earbox.net> wrote:
> >
> > On 4/20/21 3:17 AM, Alexei Starovoitov wrote:
> > > On Thu, Apr 15, 2021 at 10:47 AM Pedro Tammela <pctammela@...il.com> wrote:
> > >>
> > >> Andrii suggested to remove this abstraction layer and have the percpu
> > >> handling more explicit[1].
> > >>
> > >> This patch also updates the tests that relied on the macros.
> > >>
> > >> [1] https://lore.kernel.org/bpf/CAEf4BzYmj_ZPDq8Zi4dbntboJKRPU2TVopysBNrdd9foHTfLZw@mail.gmail.com/
> > >>
> > >> Suggested-by: Andrii Nakryiko <andrii@...nel.org>
> > >> Signed-off-by: Pedro Tammela <pctammela@...atatu.com>
> > >> ---
> > >>   tools/testing/selftests/bpf/bpf_util.h        |  7 --
> > >>   .../bpf/map_tests/htab_map_batch_ops.c        | 87 +++++++++----------
> > >>   .../selftests/bpf/prog_tests/map_init.c       |  9 +-
> > >>   tools/testing/selftests/bpf/test_maps.c       | 84 +++++++++++-------
> > >>   4 files changed, 96 insertions(+), 91 deletions(-)
> > >>
> > >> diff --git a/tools/testing/selftests/bpf/bpf_util.h b/tools/testing/selftests/bpf/bpf_util.h
> > >> index a3352a64c067..105db3120ab4 100644
> > >> --- a/tools/testing/selftests/bpf/bpf_util.h
> > >> +++ b/tools/testing/selftests/bpf/bpf_util.h
> > >> @@ -20,13 +20,6 @@ static inline unsigned int bpf_num_possible_cpus(void)
> > >>          return possible_cpus;
> > >>   }
> > >>
> > >> -#define __bpf_percpu_val_align __attribute__((__aligned__(8)))
> > >> -
> > >> -#define BPF_DECLARE_PERCPU(type, name)                         \
> > >> -       struct { type v; /* padding */ } __bpf_percpu_val_align \
> > >> -               name[bpf_num_possible_cpus()]
> > >> -#define bpf_percpu(name, cpu) name[(cpu)].v
> > >> -
> > >
> > > Hmm. I wonder what Daniel has to say about it, since he
> > > introduced it in commit f3515b5d0b71 ("bpf: provide a generic macro
> > > for percpu values for selftests")
> > > to address a class of bugs.
> >
> > I would probably even move those into libbpf instead. ;-) The problem is that this can
> > be missed easily and innocent changes would lead to corruption of the applications
> > memory if there's a map lookup. Having this at least in selftest code or even in libbpf
> > would document code-wise that care needs to be taken on per cpu maps. Even if we'd put
> > a note under Documentation/bpf/ or such, this might get missed easily and finding such
> > bugs is like looking for a needle in a haystack.. so I don't think this should be removed.
> >
>
> See [0] for previous discussion. I don't mind leaving bpf_percpu() in
> selftests. I'm not sure I ever suggested removing it from selftests,
> but I don't think it's a good idea to add it to libbpf. I think it's
> better to have an extra paragraph in bpf_lookup_map_elem() in
> uapi/linux/bpf.h mentioning how per-CPU values should be read/updated.
> I think we should just recommend to use u64 for primitive values (or
> otherwise users can embed their int in custom aligned(8) struct, if
> they insist on <u64) and __attribute__((aligned(8))) for structs.
>
>   [0] https://lore.kernel.org/bpf/CAEf4BzaLKm_fy4oO4Rdp76q2KoC6yC1WcJLuehoZUu9JobG-Cw@mail.gmail.com/
>
>
> > Thanks,
> > Daniel

OK, since this is not the main topic of this series I will revert this
patch in v5.