All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: "Jose E. Marchesi" <jose.marchesi@oracle.com>
Cc: bpf@vger.kernel.org, david.faust@oracle.com,
	cupertino.miranda@oracle.com,
	Eduard Zingerman <eddyz87@gmail.com>
Subject: Re: [PATCH bpf-next] bpf: avoid uninitialized warnings in verifier_global_subprogs.c
Date: Tue, 7 May 2024 12:46:25 -0700	[thread overview]
Message-ID: <19f42b7f-0d9d-40ac-bfae-ea6c9bc6f9f3@linux.dev> (raw)
In-Reply-To: <87edadcwm8.fsf@oracle.com>


On 5/7/24 11:20 AM, Jose E. Marchesi wrote:
>> On 5/7/24 7:05 AM, Jose E. Marchesi wrote:
>>> The BPF selftest verifier_global_subprogs.c contains code that
>>> purposedly performs out of bounds access to memory, to check whether
>>> the kernel verifier is able to catch them.  For example:
>>>
>>>     __noinline int global_unsupp(const int *mem)
>>>     {
>>> 	if (!mem)
>>> 		return 0;
>>> 	return mem[100]; /* BOOM */
>>>     }
>>>
>>> With -O1 and higher and no inlining, GCC notices this fact and emits a
>>> "maybe uninitialized" warning.  This is by design.  Note that the
>>> emission of these warnings is highly dependent on the precise
>>> optimizations that are performed.
>> Interesting. The error message is 'maybe uninitialized' but not
>> an error to complain out-of-bound access. But anyway, since gcc
>> produces a warning, your patch silences it and LGTM.
>>
>> Acked-by: Yonghong Song <yonghong.song@linux.dev>
> Please hold on.  The right warning to inhibit is -Wmaybe-uninitialized,
> which is GCC specific.
>
> So it must be:
>
>    #if !defined(__clang__)
>    #pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
>    #endif
>
> Unless you disagree I am testing this and will send a V2 with your
> Acked-by.

I thought -Wmaybe-unitialized also available to clang but just checked
that clang does not have this. So your above change looks good to me.

>
> Sorry about this.  I hate to be erratic, but so many small patches
> today.
>
>>> This patch adds a compiler pragma to verifier_global_subprogs.c to
>>> ignore these warnings.
>>>
>>> Tested in bpf-next master.
>>> No regressions.
>>>
>>> Signed-off-by: Jose E. Marchesi <jose.marchesi@oracle.com>
>>> Cc: david.faust@oracle.com
>>> Cc: cupertino.miranda@oracle.com
>>> Cc: Yonghong Song <yonghong.song@linux.dev>
>>> Cc: Eduard Zingerman <eddyz87@gmail.com>
>>> ---
>>>    tools/testing/selftests/bpf/progs/verifier_global_subprogs.c | 5 +++++
>>>    1 file changed, 5 insertions(+)
>>>
>>> diff --git
>>> a/tools/testing/selftests/bpf/progs/verifier_global_subprogs.c
>>> b/tools/testing/selftests/bpf/progs/verifier_global_subprogs.c
>>> index baff5ffe9405..d05dc218b7e9 100644
>>> --- a/tools/testing/selftests/bpf/progs/verifier_global_subprogs.c
>>> +++ b/tools/testing/selftests/bpf/progs/verifier_global_subprogs.c
>>> @@ -8,6 +8,11 @@
>>>    #include "xdp_metadata.h"
>>>    #include "bpf_kfuncs.h"
>>>    +/* The compiler may be able to detect the access to uninitialized
>>> +   memory in the routines performing out of bound memory accesses and
>>> +   emit warnings about it.  This is the case of GCC. */
>>> +#pragma GCC diagnostic ignored "-Wuninitialized"
>>> +
>>>    int arr[1];
>>>    int unkn_idx;
>>>    const volatile bool call_dead_subprog = false;

      reply	other threads:[~2024-05-07 19:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07 14:05 [PATCH bpf-next] bpf: avoid uninitialized warnings in verifier_global_subprogs.c Jose E. Marchesi
2024-05-07 17:41 ` Yonghong Song
2024-05-07 18:20   ` Jose E. Marchesi
2024-05-07 19:46     ` Yonghong Song [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19f42b7f-0d9d-40ac-bfae-ea6c9bc6f9f3@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=bpf@vger.kernel.org \
    --cc=cupertino.miranda@oracle.com \
    --cc=david.faust@oracle.com \
    --cc=eddyz87@gmail.com \
    --cc=jose.marchesi@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.