Re: WARNING: kmalloc bug in input_mt_init_slots

[Dmitry Torokhov]

On Fri, Sep 21, 2018 at 10:24 AM syzbot
<syzbot+87829a10073277282ad1@xxxxxxxxxxxxxxxxxxxxxxxxx> 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: syzbot+87829a10073277282ad1@xxxxxxxxxxxxxxxxxxxxxxxxx
>
> 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 <cl@xxxxxxxxx>
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 <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
   Signed-off-by: Christoph Lameter <cl@xxxxxxxxx>
   Link: http://lkml.kernel.org/r/201305040348.CIF81716.OStQOHFJMFLOVF@xxxxxxxxxxxxxxxxxxx
   [ penberg@xxxxxxxxxx: use WARN_ON_ONCE ]
   Signed-off-by: Pekka Enberg <penberg@xxxxxxxxxx>

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