On Tue, Apr 20, 2021 at 8:58 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > On 4/20/21 3:17 AM, Alexei Starovoitov wrote: > > On Thu, Apr 15, 2021 at 10:47 AM Pedro Tammela <pctammela@xxxxxxxxx> 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@xxxxxxxxxxxxxx/ > >> > >> Suggested-by: Andrii Nakryiko <andrii@xxxxxxxxxx> > >> Signed-off-by: Pedro Tammela <pctammela@xxxxxxxxxxxx> > >> --- > >> 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@xxxxxxxxxxxxxx/ > Thanks, > Daniel
