From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Vyukov Subject: Re: WARNING: kmalloc bug in input_mt_init_slots Date: Thu, 27 Sep 2018 17:29:11 +0200 Message-ID: References: <000000000000e5f76c057664e73d@google.com> <010001660c1fafb2-6d0dc7e1-d898-4589-874c-1be1af94e22d-000000@email.amazonses.com> <010001660c4a8bbe-91200766-00df-48bd-bc60-a03da2ccdb7d-000000@email.amazonses.com> <20180924184158.GA156847@dtor-ws> <01000166110bb882-0b1fa048-fe1c-4139-a1ba-702754bbc267-000000@email.amazonses.com> <010001661b631a3e-f398fc0a-127c-4c6e-b6ca-b2bd63bc4a9a-000000@email.amazonses.com> <010001661b9fad1d-cdbfabdb-5553-446f-bcde-585e42837415-000000@email.amazonses.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <010001661b9fad1d-cdbfabdb-5553-446f-bcde-585e42837415-000000@email.amazonses.com> Sender: linux-kernel-owner@vger.kernel.org To: Christopher Lameter Cc: Dmitry Torokhov , syzbot+87829a10073277282ad1@syzkaller.appspotmail.com, Pekka Enberg , "linux-input@vger.kernel.org" , lkml , Henrik Rydberg , syzkaller-bugs , Linux-MM List-Id: linux-input@vger.kernel.org On Thu, Sep 27, 2018 at 5:22 PM, Christopher Lameter wrote: > On Thu, 27 Sep 2018, Dmitry Vyukov wrote: > >> On Thu, Sep 27, 2018 at 4:16 PM, Christopher Lameter wrote: >> > On Thu, 27 Sep 2018, Dmitry Vyukov wrote: >> > >> >> On Tue, Sep 25, 2018 at 4:04 PM, Christopher Lameter wrote: >> >> > On Tue, 25 Sep 2018, Dmitry Vyukov wrote: >> >> > >> >> >> Assuming that the size is large enough to fail in all allocators, is >> >> >> this warning still useful? How? Should we remove it? >> >> > >> >> > Remove it. It does not make sense because we check earlier if possible >> >> > without the warn. >> >> >> >> Mailed "mm: don't warn about large allocations for slab" to remove the warning. >> >> >> > >> > Hoe it arrives here at some point. >> >> It's here: >> https://lore.kernel.org/patchwork/patch/992660/ >> > > Please post on the mailing list It is on the mailing lists: https://lkml.org/lkml/2018/9/27/802 > and NAK to the patch. Testing against > KMALLOC_MAX_CACHE_SIZE is not ok. Why?