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 <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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
On Fri, Jul 21, 2017 at 11:02 PM, Arnd Bergmann <[email protected]> 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 <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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 <[email protected]> wrote:
> On Fri, Jul 21, 2017 at 11:02 PM, Arnd Bergmann <[email protected]> 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 <[email protected]> wrote:
>> On Fri, Jul 21, 2017 at 11:02 PM, Arnd Bergmann <[email protected]> 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
<[email protected]> wrote:
> On 07/25/2017 10:17 AM, Arnd Bergmann wrote:
>> On Mon, Jul 24, 2017 at 1:35 PM, Alexander Potapenko <[email protected]> wrote:
>>> On Fri, Jul 21, 2017 at 11:02 PM, Arnd Bergmann <[email protected]> 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