Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2674880imm; Mon, 24 Sep 2018 08:11:55 -0700 (PDT) X-Google-Smtp-Source: ACcGV60QVj5fv5zDSsvwIGLJ4i2XDDiMOep4TfeoA8c8bipNtw9yv9uVPiDt+rpFSQyTndqc6y7Q X-Received: by 2002:a63:1516:: with SMTP id v22-v6mr9934135pgl.150.1537801915903; Mon, 24 Sep 2018 08:11:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537801915; cv=none; d=google.com; s=arc-20160816; b=lGFw7+nc2r4evSxew9l/kFgVwaCJ0j9ipUQB2jLBGFieRkuICVQU66PYrtr7l7dqV1 OS5r+PrAdkFOXwIHPDEgctNrTB8VQPn5xwW7+vWrsKc48qqBNZYQzAds9PO/fqqiwThn f39aqZbkoCEMlfEn0qy+WEUsGbxabRweXSjkEfGne8GsWFux3+/GiEs/LInvhZNDhKyn 2zqudL7J0iGHaZ1cPPWmgfkYD5jRdSpiSP0YmBsw6YLdlxspTN3m5i5C5Y5Xyf1/ntso P9Qd96rNrFleG03i8Bf+yrhk9v2jTw2kxy1K6YXkMMZUi7tHbZB5NLy968nB8L6q6EOD o2mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:feedback-id:mime-version:user-agent :references:message-id:in-reply-to:subject:cc:to:from:date :dkim-signature; bh=dI4W/fmojXmPulQb9arnUUExRW8ZJT9uIcqkhZa+JWo=; b=EqH+8usxkrZanb9v3SRP6Jmn7oAqh/MBPxFZd2oAoJgaPbDFaypQX+YrcYwqbYhr4x e7gGwHygg1P8E8ESaKcKWxju9Ap6iVsbiqtbQ1OC0ObWqxUfZgS5v0YZryLeOeRSgRvY hukIHW1JzHUJrP9n4dnIS2yOa9u+UrEUVbqSossooVsNOANIf7mXW3/GRezk94120PkS eCcZrJuSjMDq0OScUBWCk6hJ1hoN8O9oncvU5nIj8Z438+/LybEhnfPzkkeI2hZzWr5B Ii49swxl4Y7Y9q4BgYy1RoyuXDlzl9pVJPXhZHU6M/3L1oaY2o2xOwFemlJAKVAf7bs0 Axkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=Qvr4vUg+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w9-v6si36679744pfg.234.2018.09.24.08.11.10; Mon, 24 Sep 2018 08:11:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=Qvr4vUg+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732668AbeIXVKx (ORCPT + 99 others); Mon, 24 Sep 2018 17:10:53 -0400 Received: from a9-99.smtp-out.amazonses.com ([54.240.9.99]:43894 "EHLO a9-99.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728249AbeIXVKw (ORCPT ); Mon, 24 Sep 2018 17:10:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1537801695; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Feedback-ID; bh=dI4W/fmojXmPulQb9arnUUExRW8ZJT9uIcqkhZa+JWo=; b=Qvr4vUg+bpDIIxSAGpjhJQCFm7Kas+omqzZFJNy2DxEu+MPliw1U5JbgSDbyiKXR DoaHXWxuopDKyRs9kFE8D2tGgDJSLuhoIcACGoltVs64KhNfDET/ZIXPGLJJJ8VZ0Vr phOI4iOMPzCzQUl7I0kbO9l0cWG2MhySEKP2zE8U= Date: Mon, 24 Sep 2018 15:08:15 +0000 From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Dmitry Vyukov cc: Dmitry Torokhov , syzbot+87829a10073277282ad1@syzkaller.appspotmail.com, Pekka Enberg , "linux-input@vger.kernel.org" , lkml , Henrik Rydberg , syzkaller-bugs , Linux-MM Subject: Re: WARNING: kmalloc bug in input_mt_init_slots In-Reply-To: Message-ID: <010001660c1fafb2-6d0dc7e1-d898-4589-874c-1be1af94e22d-000000@email.amazonses.com> References: <000000000000e5f76c057664e73d@google.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SES-Outgoing: 2018.09.24-54.240.9.99 Feedback-ID: 1.us-east-1.fQZZZ0Xtj2+TD7V5apTT/NrT6QKuPgzCT/IC7XYgDKI=:AmazonSES Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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).