linux-kernel - Re: [PATCH v2] libbpf: workaround -Wmaybe-uninitialized false positive

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3c9e6cbe-f768-48b1-9e37-779971fd1146@oracle.com>
Date: Fri, 9 Aug 2024 18:48:32 +0100
From: Alan Maguire <alan.maguire@...cle.com>
To: Sam James <sam@...too.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Eduard Zingerman
 <eddyz87@...il.com>, Song Liu <song@...nel.org>,
        Yonghong Song <yonghong.song@...ux.dev>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Bill Wendling
 <morbo@...gle.com>,
        Justin Stitt <justinstitt@...gle.com>
Cc: "Jose E . Marchesi" <jose.marchesi@...cle.com>,
        Andrew Pinski <quic_apinski@...cinc.com>,
        Kacper Słomiński <kacper.slominski72@...il.com>,
        Arsen Arsenović <arsen@...too.org>,
        bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
        llvm@...ts.linux.dev
Subject: Re: [PATCH v2] libbpf: workaround -Wmaybe-uninitialized false
 positive

On 09/08/2024 18:26, Sam James wrote:
> In `elf_close`, we get this with GCC 15 -O3 (at least):
> ```
> In function ‘elf_close’,
>     inlined from ‘elf_close’ at elf.c:53:6,
>     inlined from ‘elf_find_func_offset_from_file’ at elf.c:384:2:
> elf.c:57:9: warning: ‘elf_fd.elf’ may be used uninitialized [-Wmaybe-uninitialized]
>    57 |         elf_end(elf_fd->elf);
>       |         ^~~~~~~~~~~~~~~~~~~~
> elf.c: In function ‘elf_find_func_offset_from_file’:
> elf.c:377:23: note: ‘elf_fd.elf’ was declared here
>   377 |         struct elf_fd elf_fd;
>       |                       ^~~~~~
> In function ‘elf_close’,
>     inlined from ‘elf_close’ at elf.c:53:6,
>     inlined from ‘elf_find_func_offset_from_file’ at elf.c:384:2:
> elf.c:58:9: warning: ‘elf_fd.fd’ may be used uninitialized [-Wmaybe-uninitialized]
>    58 |         close(elf_fd->fd);
>       |         ^~~~~~~~~~~~~~~~~
> elf.c: In function ‘elf_find_func_offset_from_file’:
> elf.c:377:23: note: ‘elf_fd.fd’ was declared here
>   377 |         struct elf_fd elf_fd;
>       |                       ^~~~~~
> ```
> 
> In reality, our use is fine, it's just that GCC doesn't model errno
> here (see linked GCC bug). Suppress -Wmaybe-uninitialized accordingly.
> 
> Link: https://gcc.gnu.org/PR114952
> Signed-off-by: Sam James <sam@...too.org>
> ---
> v2: Fix Clang build.
> 
> Range-diff against v1:
> 1:  3ebbe7a4e93a ! 1:  8f5c3b173e4c libbpf: workaround -Wmaybe-uninitialized false positive
>     @@ tools/lib/bpf/elf.c: long elf_find_func_offset(Elf *elf, const char *binary_path
>       	return ret;
>       }
>       
>     ++#if !defined(__clang__)
>      +#pragma GCC diagnostic push
>      +/* https://gcc.gnu.org/PR114952 */
>      +#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
>     ++#endif
>       /* Find offset of function name in ELF object specified by path. "name" matches
>        * symbol name or name@@LIB for library functions.
>        */
>     @@ tools/lib/bpf/elf.c: long elf_find_func_offset_from_file(const char *binary_path
>       	elf_close(&elf_fd);
>       	return ret;
>       }
>     ++#if !defined(__clang__)
>      +#pragma GCC diagnostic pop
>     ++#endif
>       
>       struct symbol {
>       	const char *name;
> 
>  tools/lib/bpf/elf.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/tools/lib/bpf/elf.c b/tools/lib/bpf/elf.c
> index c92e02394159..7058425ca85b 100644
> --- a/tools/lib/bpf/elf.c
> +++ b/tools/lib/bpf/elf.c
> @@ -369,6 +369,11 @@ long elf_find_func_offset(Elf *elf, const char *binary_path, const char *name)
>  	return ret;
>  }
>  
> +#if !defined(__clang__)
> +#pragma GCC diagnostic push
> +/* https://gcc.gnu.org/PR114952 */
> +#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
> +#endif
>  /* Find offset of function name in ELF object specified by path. "name" matches
>   * symbol name or name@@LIB for library functions.
>   */
> @@ -384,6 +389,9 @@ long elf_find_func_offset_from_file(const char *binary_path, const char *name)
>  	elf_close(&elf_fd);
>  	return ret;
>  }
> +#if !defined(__clang__)
> +#pragma GCC diagnostic pop
> +#endif
>  
>  struct symbol {
>  	const char *name;


Would just initializing struct elf_fd be enough to silence the error
perhaps, i.e.

diff --git a/tools/lib/bpf/elf.c b/tools/lib/bpf/elf.c
index c92e02394159..3060597a527e 100644
--- a/tools/lib/bpf/elf.c
+++ b/tools/lib/bpf/elf.c
@@ -374,7 +374,7 @@ long elf_find_func_offset(Elf *elf, const char
*binary_path, const char *name)
  */
 long elf_find_func_offset_from_file(const char *binary_path, const char
*name)
 {
-       struct elf_fd elf_fd;
+       struct elf_fd elf_fd = { .fd = -1 };
        long ret = -ENOENT;

        ret = elf_open(binary_path, &elf_fd);