Messages in this thread | | | From | Arnd Bergmann <> | Date | Tue, 25 Jul 2017 16:51:33 +0200 | Subject | Re: [PATCH] [v2] kasan: avoid -Wmaybe-uninitialized warning |
| |
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
| |