[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG_fn=WpeCq70LGqt+GiYDSO72uvNWYndG+rGyMJzVuaFUcNQw@mail.gmail.com>
Date: Wed, 22 Mar 2017 18:33:53 +0100
From: Alexander Potapenko <glider@...gle.com>
To: Andrey Konovalov <andreyknvl@...gle.com>
Cc: Andrey Ryabinin <aryabinin@...tuozzo.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Mark Rutland <mark.rutland@....com>,
Dmitry Vyukov <dvyukov@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>,
Linux Memory Management List <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kasan: report only the first error
On Wed, Mar 22, 2017 at 6:07 PM, Andrey Konovalov <andreyknvl@...gle.com> wrote:
> On Wed, Mar 22, 2017 at 5:54 PM, Andrey Ryabinin
> <aryabinin@...tuozzo.com> wrote:
>> On 03/22/2017 07:34 PM, Andrey Konovalov wrote:
>>> On Wed, Mar 22, 2017 at 5:06 PM, Andrey Ryabinin
>>> <aryabinin@...tuozzo.com> wrote:
>>>> Disable kasan after the first report. There are several reasons for this:
>>>> * Single bug quite often has multiple invalid memory accesses causing
>>>> storm in the dmesg.
>>>> * Write OOB access might corrupt metadata so the next report will print
>>>> bogus alloc/free stacktraces.
>>>> * Reports after the first easily could be not bugs by itself but just side
>>>> effects of the first one.
>>>>
>>>> Given that multiple reports only do harm, it makes sense to disable
>>>> kasan after the first one. Except for the tests in lib/test_kasan.c
>>>> as we obviously want to see all reports from test.
>>>
>>> Hi Andrey,
>>>
>>> Could you make it configurable via CONFIG_KASAN_SOMETHING (which can
>>> default to showing only the first report)?
>>
>> I'd rather make this boot time configurable, but wouldn't want to without
>> a good reason.
>
> That would work for me.
>
>>
>>
>>> I sometimes use KASAN to see what bad accesses a particular bug
>>> causes, and seeing all of them (even knowing that they may be
>>> corrupt/induced) helps a lot.
>>
>> I'm wondering why you need to see all reports?
>
> To get a better picture of what are the consequences of a bug. For
> example whether it leads to some bad or controllable memory
> corruption. Sometimes it's easier to let KASAN track the memory
> accesses then do that manually.
Another case is when you're seeing an OOB read at boot time, which has
limited impact, and you don't want to wait for the code owner to fix
it to move forward.
>>
>>>
>>> Thanks!
>>>
--
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
Powered by blists - more mailing lists