On Wed, Mar 22, 2017 at 6:07 PM, Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote: > On Wed, Mar 22, 2017 at 5:54 PM, Andrey Ryabinin > <aryabinin@xxxxxxxxxxxxx> wrote: >> On 03/22/2017 07:34 PM, Andrey Konovalov wrote: >>> On Wed, Mar 22, 2017 at 5:06 PM, Andrey Ryabinin >>> <aryabinin@xxxxxxxxxxxxx> 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
