Em ter., 20 de abr. de 2021 às 13:42, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> escreveu: > > 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 OK, since this is not the main topic of this series I will revert this patch in v5.
