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
| ||
|
Date: Thu, 30 Apr 2020 16:25:45 +0200 From: Daniel Borkmann <daniel@...earbox.net> To: Jakub Sitnicki <jakub@...udflare.com>, Andrii Nakryiko <andriin@...com> Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, ast@...com, andrii.nakryiko@...il.com, kernel-team@...com Subject: Re: [PATCH v2 bpf-next] libbpf: fix false uninitialized variable warning On 4/30/20 10:13 AM, Jakub Sitnicki wrote: > On Thu, Apr 30, 2020 at 04:14 AM CEST, Andrii Nakryiko wrote: >> Some versions of GCC falsely detect that vi might not be initialized. That's >> not true, but let's silence it with NULL initialization. >> >> Signed-off-by: Andrii Nakryiko <andriin@...com> >> --- >> tools/lib/bpf/libbpf.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c >> index d86ff8214b96..977add1b73e2 100644 >> --- a/tools/lib/bpf/libbpf.c >> +++ b/tools/lib/bpf/libbpf.c >> @@ -5003,8 +5003,8 @@ static int bpf_object__collect_map_relos(struct bpf_object *obj, >> GElf_Shdr *shdr, Elf_Data *data) >> { >> int i, j, nrels, new_sz, ptr_sz = sizeof(void *); >> + const struct btf_var_secinfo *vi = NULL; >> const struct btf_type *sec, *var, *def; >> - const struct btf_var_secinfo *vi; >> const struct btf_member *member; >> struct bpf_map *map, *targ_map; >> const char *name, *mname; > > Alternatively we could borrow the kernel uninitialized_var macro: > > include/linux/compiler-clang.h:#define uninitialized_var(x) x = *(&(x)) > include/linux/compiler-gcc.h:#define uninitialized_var(x) x = x We could do that potentially, at least to mark such locations explicitly, although I wonder if it's not more churn than anything else adding the infra for it. But generally no objections from my side. Anyway, applied this one, thanks!
Powered by blists - more mailing lists