Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2290140imm; Thu, 27 Sep 2018 10:19:28 -0700 (PDT) X-Google-Smtp-Source: ACcGV61vn0gOXaOqJHxHK3Zn8fvx6clujv4Mj578ok5wsuxjNJPZJ228TWE7eB5Y1cF9lsvsNF6G X-Received: by 2002:a63:dd49:: with SMTP id g9-v6mr11029788pgj.356.1538068768215; Thu, 27 Sep 2018 10:19:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538068768; cv=none; d=google.com; s=arc-20160816; b=h7SY3PV1Ju9ElJ6WuKvG7Ay7SqGbaFfza2tZsuxQwYOE3mG7bFsZD9SYD42ZSMTBCN dh3wbd+FDTopfCHum1KqGlxf1EfX0MFmeS8S2PrzBDa/Ywh1vmbPxqVc6CcjVKnYNyJY WCYoUAirdynXpdV2hxaBtD+EZPr7ZTjHXNW2VEmA1DKp9R9fqRLVo9O0VWostuIgOvlS yi1G2buZ7rxaV65ZcNmOWA+wAPfZ8aqwZWeoXMVNeGcqAPfDvRUr5AsXOKqf4mwqZf9b BzRFgMyixij/fSUwcaxbyhYl5XfQlJpLIvWAKuDgFbFxHhajoMvCTJEU2iQdWZaq6OI/ duQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=zb6LHi+FvjIQDGgKJlWbS8EePaue+YRWWkZ5bo/1YOE=; b=Od40tBqQ0dUHzWQAjdW9XOjdUj83nDrGOy26lbjiEYmUwswLcMy6dtJA6JmllYn6gE YUisWLAZytMpBW/9tkftlQUgn9Tl7Jcv5zJGNuarPAi/QghUmvJ8XhqAeFX6ISujQdm8 fArmhkGC5eGyNEJr1aj3Uvjvv3O6dL2XmMoSz12ljCGxp5vhKHUd6TC6uswZ0qguKIO7 Y9A5PDCYbjf1l60OX912tq4P0tUAbVb6LrWKHFUMnFIw0pw5c/M9rKdPLowMWwrFdJ/Z UnYuWCnDtIuum5JiE1cgoOQPj+I4GCkMLRPlnpMhBzA0Sg5jgeemdu1i0aVs0Yrx+07K 0mXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=J4DwZhwT; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10-v6si2319439pgi.223.2018.09.27.10.17.59; Thu, 27 Sep 2018 10:19:28 -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=@google.com header.s=20161025 header.b=J4DwZhwT; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728451AbeI0Xgj (ORCPT + 99 others); Thu, 27 Sep 2018 19:36:39 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:41980 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727437AbeI0Xgj (ORCPT ); Thu, 27 Sep 2018 19:36:39 -0400 Received: by mail-io1-f68.google.com with SMTP id q4-v6so2456680iob.8 for ; Thu, 27 Sep 2018 10:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zb6LHi+FvjIQDGgKJlWbS8EePaue+YRWWkZ5bo/1YOE=; b=J4DwZhwTI3XsmynMzOde2gwxzhy0+gTi10rg5dL45kXTusD9SuGkPRkdm29xznEz1N FVLXCvyMk+Nvqke3yD0gYg44TIh4whtLzU9Fqsday5kGyyg3eppdSQy318/HMAMyyuJ7 mCkXXRj0HE7JtiKil9fjLMn5vAAnYdfTfYktMFChK97mG4w0H9DzzDCHgDwcCt/tH4q7 YWOFXY1HQ5lDz9hZWvfJtHrCKBjZL9Q4WLoPRZfd1WfG0MZTwEx4FnAgJYDDKoCmZDPX 4vDqHH4NpodDVJ+GV+7sFy22nWRzY91NVkisxmd6mTH2y5YODY5rVYOVAJBdW/FQ4mcb 98tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zb6LHi+FvjIQDGgKJlWbS8EePaue+YRWWkZ5bo/1YOE=; b=aiNes8mbZpRX5hxRS8Gcz6KmDan3dfYHKQG5WYRG0IHWtdwW7I7tPpGXLpEvoiJmIT cFlme3oVaNFUsjNN+GanB9vJbyQ76MwbCfM7PMZi6OkaKqXphr/sjTRFe0PMfDgGz2OY +24zJsPbtVSsd8wYAh2jurJVHnnDWFc/T9LX9yjwTXysv5f5EiktfA6mqCIbkwues56k p2WILIbehBamuJuD3nhFh5t3bE3SlNrV7yT/A9x+RWqgv4nBPo/AFlc9NLht27EkBDEW qSE0O6rMEkzqtfqutOFZWZxh92qOC/x4m7m0Dl87P7QU8nZqW+sodc2JjW5mVzOcGD6G tYow== X-Gm-Message-State: ABuFfoj2rd0AtRHnSxr99Z6v/K9Ref4b68FxssZ8xVdYWRmKI/n2Of8J CkdMPHzYFT8hNFnvftkaOQKv6lUnW173E1PBIDV+vQ== X-Received: by 2002:a6b:f316:: with SMTP id m22-v6mr8865087ioh.271.1538068641657; Thu, 27 Sep 2018 10:17:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:ab8c:0:0:0:0:0 with HTTP; Thu, 27 Sep 2018 10:17:01 -0700 (PDT) In-Reply-To: <010001661bba2bbc-a5074e00-2009-414a-be8c-05c58545c7ec-000000@email.amazonses.com> References: <20180927130707.151239-1-dvyukov@gmail.com> <010001661bba2bbc-a5074e00-2009-414a-be8c-05c58545c7ec-000000@email.amazonses.com> From: Dmitry Vyukov Date: Thu, 27 Sep 2018 19:17:01 +0200 Message-ID: Subject: Re: [PATCH] mm: don't warn about large allocations for slab To: Christopher Lameter Cc: Dmitry Vyukov , Pekka Enberg , Andrew Morton , David Rientjes , Joonsoo Kim , Linux-MM , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 27, 2018 at 5:51 PM, Christopher Lameter wrote: > On Thu, 27 Sep 2018, Dmitry Vyukov wrote: > >> From: Dmitry Vyukov >> >> This warning does not seem to be useful. Most of the time it fires when >> allocation size depends on syscall arguments. We could add __GFP_NOWARN >> to these allocation sites, but having a warning only to suppress it >> does not make lots of sense. Moreover, this warnings never fires for >> constant-size allocations and never for slub, because there are >> additional checks and fallback to kmalloc_large() for large allocations >> and kmalloc_large() does not warn. So the warning only fires for >> non-constant allocations and only with slab, which is odd to begin with. >> The warning leads to episodic unuseful syzbot reports. Remote it. > > /Remove/ > > If its only for slab then KMALLOC_MAX_CACHE_SIZE and KMALLOC_MAX_SIZE are > the same value. > >> While we are here also fix the check. We should check against >> KMALLOC_MAX_CACHE_SIZE rather than KMALLOC_MAX_SIZE. It all kinda >> worked because for slab the constants are the same, and slub always >> checks the size against KMALLOC_MAX_CACHE_SIZE before kmalloc_slab(). >> But if we get there with size > KMALLOC_MAX_CACHE_SIZE anyhow >> bad things will happen. > > Then the WARN_ON is correct just change the constant used. Ensure that > SLAB does the same checks as SLUB. Mailed v2 which adds the checks to slab. I think the warning is still slightly wrong. It means a bug in slab code, it has nothing to do with user-passed flags.