diff options
| author | Andrii Nakryiko <[email protected]> | 2020-01-10 18:19:16 +0000 |
|---|---|---|
| committer | Alexei Starovoitov <[email protected]> | 2020-01-10 18:38:00 +0000 |
| commit | 1d1a3bcffe360a56fd8cc287ed74d4c3066daf42 (patch) | |
| tree | a5dd199f093ed5cd8a2dd179c2682ea5520b26b5 /tools/lib/bpf/hashmap.c | |
| parent | Merge branch 'bpf-global-funcs' (diff) | |
| download | kernel-1d1a3bcffe360a56fd8cc287ed74d4c3066daf42.tar.gz kernel-1d1a3bcffe360a56fd8cc287ed74d4c3066daf42.zip | |
libbpf: Poison kernel-only integer types
It's been a recurring issue with types like u32 slipping into libbpf source
code accidentally. This is not detected during builds inside kernel source
tree, but becomes a compilation error in libbpf's Github repo. Libbpf is
supposed to use only __{s,u}{8,16,32,64} typedefs, so poison {s,u}{8,16,32,64}
explicitly in every .c file. Doing that in a bit more centralized way, e.g.,
inside libbpf_internal.h breaks selftests, which are both using kernel u32 and
libbpf_internal.h.
This patch also fixes a new u32 occurence in libbpf.c, added recently.
Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support")
Signed-off-by: Andrii Nakryiko <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Acked-by: Martin KaFai Lau <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Diffstat (limited to 'tools/lib/bpf/hashmap.c')
| -rw-r--r-- | tools/lib/bpf/hashmap.c | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/tools/lib/bpf/hashmap.c b/tools/lib/bpf/hashmap.c index 6122272943e6..54c30c802070 100644 --- a/tools/lib/bpf/hashmap.c +++ b/tools/lib/bpf/hashmap.c @@ -12,6 +12,9 @@ #include <linux/err.h> #include "hashmap.h" +/* make sure libbpf doesn't use kernel-only integer typedefs */ +#pragma GCC poison u8 u16 u32 u64 s8 s16 s32 s64 + /* start with 4 buckets */ #define HASHMAP_MIN_CAP_BITS 2 |