All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, david.faust@oracle.com,
	cupertino.miranda@oracle.com,
	Eduard Zingerman <eddyz87@gmail.com>,
	Yonghong Song <yonghong.song@linux.dev>
Subject: Re: [PATCH bpf-next] bpf: avoid uninitialized value in BPF_CORE_READ_BITFIELD
Date: Tue, 07 May 2024 20:14:04 +0200	[thread overview]
Message-ID: <87v83pcwwj.fsf@oracle.com> (raw)
In-Reply-To: <CAEf4BzZ259J6M+y5xVakycqVPgU3vjP3_qWFMuyZKDkVn68ysg@mail.gmail.com> (Andrii Nakryiko's message of "Tue, 7 May 2024 09:41:47 -0700")


> On Tue, May 7, 2024 at 4:40 AM Jose E. Marchesi
> <jose.marchesi@oracle.com> wrote:
>>
>> GCC warns that `val' may be used uninitialized in the
>> BPF_CORE_READ_BITFIELD macro, defined in bpf_core_read.h as:
>>
>>         [...]
>>         unsigned long long val;                                               \
>>         [...]                                                                 \
>>         switch (__CORE_RELO(s, field, BYTE_SIZE)) {                           \
>>         case 1: val = *(const unsigned char *)p; break;                       \
>>         case 2: val = *(const unsigned short *)p; break;                      \
>>         case 4: val = *(const unsigned int *)p; break;                        \
>>         case 8: val = *(const unsigned long long *)p; break;                  \
>>         }                                                                     \
>>         [...]
>>         val;                                                                  \
>>         }                                                                     \
>>
>> This patch initializes `val' to zero in order to avoid the warning,
>> and random values to be used in case __builtin_preserve_field_info
>> returns unexpected values for BPF_FIELD_BYTE_SIZE.
>>
>> 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: Eduard Zingerman <eddyz87@gmail.com>
>> Cc: Yonghong Song <yonghong.song@linux.dev>
>> ---
>>  tools/lib/bpf/bpf_core_read.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.h
>> index b5c7ce5c243a..88d129b5f0a1 100644
>> --- a/tools/lib/bpf/bpf_core_read.h
>> +++ b/tools/lib/bpf/bpf_core_read.h
>> @@ -89,7 +89,7 @@ enum bpf_enum_value_kind {
>>   */
>>  #define BPF_CORE_READ_BITFIELD(s, field) ({                                  \
>>         const void *p = (const void *)s + __CORE_RELO(s, field, BYTE_OFFSET); \
>> -       unsigned long long val;                                               \
>> +       unsigned long long val = 0;                                           \
>
> let's add instead `default: val = 0; break;`
>
> as Yonghong mentioned, it's not expected to have invalid byte size
> value in the relocation

Ok.  I will send a V2 with that change.

> pw-bot: cr
>
>>                                                                               \
>>         /* This is a so-called barrier_var() operation that makes specified   \
>>          * variable "a black box" for optimizing compiler.                    \
>> --
>> 2.30.2
>>
>>

      reply	other threads:[~2024-05-07 18:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07 11:39 [PATCH bpf-next] bpf: avoid uninitialized value in BPF_CORE_READ_BITFIELD Jose E. Marchesi
2024-05-07 16:23 ` Yonghong Song
2024-05-07 18:13   ` Jose E. Marchesi
2024-05-07 16:41 ` Andrii Nakryiko
2024-05-07 18:14   ` Jose E. Marchesi [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=87v83pcwwj.fsf@oracle.com \
    --to=jose.marchesi@oracle.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=cupertino.miranda@oracle.com \
    --cc=david.faust@oracle.com \
    --cc=eddyz87@gmail.com \
    --cc=yonghong.song@linux.dev \
    /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.