On Fri, Sep 21, 2018 at 10:24 AM syzbot
<[email protected]> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:    234b69e3e089 ocfs2: fix ocfs2 read block panic
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=131f761a400000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
> dashboard link: https://syzkaller.appspot.com/bug?extid=87829a10073277282ad1
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=126ca61a400000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=119d6511400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: [email protected]
>
> input: syz0 as /devices/virtual/input/input25382
> WARNING: CPU: 0 PID: 11238 at mm/slab_common.c:1031 kmalloc_slab+0x56/0x70
> mm/slab_common.c:1031
> Kernel panic - not syncing: panic_on_warn set ...

This is coming from:

commit 6286ae97d10ea2b5cd90532163797ab217bfdbdf
Author: Christoph Lameter <[email protected]>
Date:   Fri May 3 15:43:18 2013 +0000

   slab: Return NULL for oversized allocations

   The inline path seems to have changed the SLAB behavior for very large
   kmalloc allocations with  commit e3366016 ("slab: Use common
   kmalloc_index/kmalloc_size functions"). This patch restores the old
   behavior but also adds diagnostics so that we can figure where in the
   code these large allocations occur.

   Reported-and-tested-by: Tetsuo Handa <[email protected]>
   Signed-off-by: Christoph Lameter <[email protected]>
   Link: 
http://lkml.kernel.org/r/[email protected]
   [ [email protected]: use WARN_ON_ONCE ]
   Signed-off-by: Pekka Enberg <[email protected]>

You'll have to convince Cristoph that WARN_ON_ONCE() there is evil and
has to be eradicated so that KASAN can run (but then we'd not know
easily that some allocation failed because it was too big and never
had a chance of succeeding vs. ordinary memory failure).

Can I recommend that maybe you introduce infrastructure for
panic_on_warn to ignore certain "well known" warnings?

Thanks.

-- 
Dmitry

Reply via email to