On 4/20/21 3:17 AM, Alexei Starovoitov wrote:
On Thu, Apr 15, 2021 at 10:47 AM Pedro Tammela <pctamm...@gmail.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_zpdq8zi4dbntbojkrpu2tvopysbnrdd9fohtf...@mail.gmail.com/

Suggested-by: Andrii Nakryiko <and...@kernel.org>
Signed-off-by: Pedro Tammela <pctamm...@mojatatu.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.

Thanks,
Daniel

Reply via email to