From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by kanga.kvack.org (Postfix) with ESMTP id 830128E0072 for ; Tue, 25 Sep 2018 03:40:14 -0400 (EDT) Received: by mail-io1-f69.google.com with SMTP id m15-v6so44244506ioj.22 for ; Tue, 25 Sep 2018 00:40:14 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id c65-v6sor637004itc.93.2018.09.25.00.40.13 for (Google Transport Security); Tue, 25 Sep 2018 00:40:13 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180924184158.GA156847@dtor-ws> 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> From: Dmitry Vyukov Date: Tue, 25 Sep 2018 09:39:52 +0200 Message-ID: Subject: Re: WARNING: kmalloc bug in input_mt_init_slots Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Dmitry Torokhov Cc: Christopher Lameter , syzbot+87829a10073277282ad1@syzkaller.appspotmail.com, Pekka Enberg , "linux-input@vger.kernel.org" , lkml , Henrik Rydberg , syzkaller-bugs , Linux-MM On Mon, Sep 24, 2018 at 8:41 PM, Dmitry Torokhov wrote: > On Mon, Sep 24, 2018 at 03:55:04PM +0000, Christopher Lameter wrote: >> On Mon, 24 Sep 2018, Dmitry Vyukov wrote: >> >> > On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter wrote: >> > > On Sun, 23 Sep 2018, Dmitry Vyukov wrote: >> > > >> > >> What was the motivation behind that WARNING about large allocations in >> > >> kmalloc? Why do we want to know about them? Is the general policy that >> > >> kmalloc calls with potentially large size requests need to use NOWARN? >> > >> If this WARNING still considered useful? Or we should change it to >> > >> pr_err? >> > > >> > > In general large allocs should be satisfied by the page allocator. The >> > > slab allocators are used for allocating and managing small objects. The >> > > page allocator has mechanisms to deal with large objects (compound pages, >> > > multiple page sized allocs etc). >> > >> > I am asking more about the status of this warning. If it fires in >> > input_mt_init_slots(), does it mean that input_mt_init_slots() needs >> > to be fixed? If not, then we need to change this warning to something >> > else. >> >> Hmmm.. kmalloc falls back to the page allocator already? >> >> See >> >> static __always_inline void *kmalloc(size_t size, gfp_t flags) >> { >> if (__builtin_constant_p(size)) { > > It would not be a constant here though. > >> if (size > KMALLOC_MAX_CACHE_SIZE) >> return kmalloc_large(size, flags); >> >> >> Note that this uses KMALLOC_MAX_CACHE_SIZE which should be smaller than >> KMALLOC_MAX_SIZE. >> >> >> How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE >> are larger than the maximum allowed by the page allocator. Thus the warning >> and the NULL return. > > The size in this particular case is being derived from a value passed > from userspace. Input core does not care about any limits on size of > memory kmalloc() can support and is perfectly happy with getting NULL > and telling userspace to go away with their silly requests by returning > -ENOMEM. > > For the record: I definitely do not want to pre-sanitize size neither in > uinput nor in input core. Christopher, Assuming that the size is large enough to fail in all allocators, is this warning still useful? How? Should we remove it?