Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1693988 > unrolled thread

[PATCH] [v2] kasan: avoid -Wmaybe-uninitialized warning

Back to article view | Back to linux.kernel

Contents

  [PATCH] [v2] kasan: avoid -Wmaybe-uninitialized warning Arnd Bergmann <arnd@arndb.de> - 2017-07-21 23:10 +0200
    Re: [PATCH] [v2] kasan: avoid -Wmaybe-uninitialized warning Alexander Potapenko <glider@google.com> - 2017-07-24 13:40 +0200
      Re: [PATCH] [v2] kasan: avoid -Wmaybe-uninitialized warning Arnd Bergmann <arnd@arndb.de> - 2017-07-25 09:20 +0200
        Re: [PATCH] [v2] kasan: avoid -Wmaybe-uninitialized warning Arnd Bergmann <arnd@arndb.de> - 2017-07-25 17:00 +0200

#1693988 — [PATCH] [v2] kasan: avoid -Wmaybe-uninitialized warning

gcc-7 produces this warning:

mm/kasan/report.c: In function 'kasan_report':
mm/kasan/report.c:351:3: error: 'info.first_bad_addr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
   print_shadow_for_address(info->first_bad_addr);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/kasan/report.c:360:27: note: 'info.first_bad_addr' was declared here

The code seems fine as we only print info.first_bad_addr when there is a shadow,
and we always initialize it in that case, but this is relatively hard
for gcc to figure out after the latest rework. Adding an intialization
in the other code path gets rid of the warning.

Fixes: b235b9808664 ("kasan: unify report headers")
Link: https://patchwork.kernel.org/patch/9641417/
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Originally submitted on March 23, but unfortunately is still needed,
as verified on 4.13-rc1, with aarch64-linux-gcc-7.1.1

v2: add a comment as Andrew suggested
---
 mm/kasan/report.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 04bb1d3eb9ec..28fb222ab149 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -111,6 +111,9 @@ static const char *get_wild_bug_type(struct kasan_access_info *info)
 {
 	const char *bug_type = "unknown-crash";
 
+	/* shut up spurious -Wmaybe-uninitialized warning */
+	info->first_bad_addr = (void *)(-1ul);
+
 	if ((unsigned long)info->access_addr < PAGE_SIZE)
 		bug_type = "null-ptr-deref";
 	else if ((unsigned long)info->access_addr < TASK_SIZE)
-- 
2.9.0

[toc] | [next] | [standalone]

#1694652

On Fri, Jul 21, 2017 at 11:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> gcc-7 produces this warning:
>
> mm/kasan/report.c: In function 'kasan_report':
> mm/kasan/report.c:351:3: error: 'info.first_bad_addr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>    print_shadow_for_address(info->first_bad_addr);
>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> mm/kasan/report.c:360:27: note: 'info.first_bad_addr' was declared here
>
> The code seems fine as we only print info.first_bad_addr when there is a shadow,
> and we always initialize it in that case, but this is relatively hard
> for gcc to figure out after the latest rework. Adding an intialization
> in the other code path gets rid of the warning.
>
> Fixes: b235b9808664 ("kasan: unify report headers")
> Link: https://patchwork.kernel.org/patch/9641417/
> Acked-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Originally submitted on March 23, but unfortunately is still needed,
> as verified on 4.13-rc1, with aarch64-linux-gcc-7.1.1
>
> v2: add a comment as Andrew suggested
> ---
>  mm/kasan/report.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 04bb1d3eb9ec..28fb222ab149 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -111,6 +111,9 @@ static const char *get_wild_bug_type(struct kasan_access_info *info)
>  {
>         const char *bug_type = "unknown-crash";
>
> +       /* shut up spurious -Wmaybe-uninitialized warning */
> +       info->first_bad_addr = (void *)(-1ul);
> +
Why don't we initialize info.first_bad_addr in kasan_report(), where
info is allocated?
>         if ((unsigned long)info->access_addr < PAGE_SIZE)
>                 bug_type = "null-ptr-deref";
>         else if ((unsigned long)info->access_addr < TASK_SIZE)
> --
> 2.9.0
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[toc] | [prev] | [next] | [standalone]

#1695426

On Mon, Jul 24, 2017 at 1:35 PM, Alexander Potapenko <glider@google.com> wrote:
> On Fri, Jul 21, 2017 at 11:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:

>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
>> index 04bb1d3eb9ec..28fb222ab149 100644
>> --- a/mm/kasan/report.c
>> +++ b/mm/kasan/report.c
>> @@ -111,6 +111,9 @@ static const char *get_wild_bug_type(struct kasan_access_info *info)
>>  {
>>         const char *bug_type = "unknown-crash";
>>
>> +       /* shut up spurious -Wmaybe-uninitialized warning */
>> +       info->first_bad_addr = (void *)(-1ul);
>> +
> Why don't we initialize info.first_bad_addr in kasan_report(), where
> info is allocated?

I'm just trying to shut up a particular warning here where gcc can't figure out
by itself that it is initialized. Setting an invalid address at
allocation time would
prevent gcc from warning even for any trivial bug where we use the incorrect
value in the normal code path, in case someone later wants to modify the
code further and makes a mistake.

       Arnd

[toc] | [prev] | [next] | [standalone]

#1695813

On Tue, Jul 25, 2017 at 2:06 PM, Andrey Ryabinin
<aryabinin@virtuozzo.com> wrote:
> On 07/25/2017 10:17 AM, Arnd Bergmann wrote:
>> On Mon, Jul 24, 2017 at 1:35 PM, Alexander Potapenko <glider@google.com> wrote:
>>> On Fri, Jul 21, 2017 at 11:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
>>>> index 04bb1d3eb9ec..28fb222ab149 100644
>>>> --- a/mm/kasan/report.c
>>>> +++ b/mm/kasan/report.c
>>>> @@ -111,6 +111,9 @@ static const char *get_wild_bug_type(struct kasan_access_info *info)
>>>>  {
>>>>         const char *bug_type = "unknown-crash";
>>>>
>>>> +       /* shut up spurious -Wmaybe-uninitialized warning */
>>>> +       info->first_bad_addr = (void *)(-1ul);
>>>> +
>>> Why don't we initialize info.first_bad_addr in kasan_report(), where
>>> info is allocated?
>>
>> I'm just trying to shut up a particular warning here where gcc can't figure out
>> by itself that it is initialized. Setting an invalid address at
>> allocation time would
>> prevent gcc from warning even for any trivial bug where we use the incorrect
>> value in the normal code path, in case someone later wants to modify the
>> code further and makes a mistake.
>>
>
> 'info->first_bad_addr' could be initialized to the correct value. That would be 'addr' itself
> for 'wild' type of bugs.
> Initialization in get_wild_bug_type() looks a bit odd and off-place.

Yes, that makes sense. I'll send a new version then.

        Arnd

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web