| Message ID | 20170721210251.3378996-1-arnd@arndb.de |
|---|---|
| State | New |
| Headers | show |
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
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
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.
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
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)
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(+) -- 2.9.0