From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E66BBC282C2 for ; Wed, 13 Feb 2019 18:08:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BA27D20811 for ; Wed, 13 Feb 2019 18:08:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="GJgFZO1Q" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727348AbfBMSI6 (ORCPT ); Wed, 13 Feb 2019 13:08:58 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:41583 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727937AbfBMSI5 (ORCPT ); Wed, 13 Feb 2019 13:08:57 -0500 Received: by mail-lj1-f196.google.com with SMTP id e17-v6so2832247lja.8 for ; Wed, 13 Feb 2019 10:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e+LQWnqULW+l6EMSnspy1Pa7LnelXaU8iBmL+OFW3Oc=; b=GJgFZO1QUUbKQ41XirqInswpyPhw8V0Q7enJjpCSXV042beuF5aL8nKpSquwC8PANn cmA/rsEK/2YiiDDCXV1wihj2JUXRaxIguoLa8a0UYmK46816Y3utsUVpzrMQAd0bwaPh pQ0q7Paz+Cnt+TvDESIeUsKcmn3af1g1janxI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e+LQWnqULW+l6EMSnspy1Pa7LnelXaU8iBmL+OFW3Oc=; b=P1e0mlrEQUblWmEDcLZJZMc4vhun79TfEzLso3kuciXes9QyJs3dYEIsU5c7dEKyLC rzuLrQaflduCwOqXzQeBSyJ8kJigZEPdmi2MtaWWW1tmrRxVBRDNpm9nVUHlXEYEZ6h0 HjJPph9IIiZaX3tUM9+Vej1RSU5ldEOXNzonvpssUdK6TCxyGebdcsAGFiHfJvYVk+mK LXB3UglkhNts2HRByZRLjur/Q/z2AOOzAPk7J+MxgVSQp6uSFIWdNFSr0b55eXEZE5DO e80aw3pM6HAIB8QDEKCCdRL9rl/mjH1FibXAJbjJJfLBaz7M9Oll2NteAzuf58tgs1aE BM9w== X-Gm-Message-State: AHQUAuZnzEsM+wz9wD6eSxl8a5hNmwyApiw+7YOKEpvK8SMQV1ncR4Qf hEuLz2JWccvS9rlO9l3PPVFL8VMLcyI= X-Google-Smtp-Source: AHgI3IajVmRnJzzL94NdWXs2VII08dzmq3iK0ZORm5TCzvcBjRKaiLFbO6lJPFh/9FLeC0bJKEooHQ== X-Received: by 2002:a2e:8949:: with SMTP id b9mr1084681ljk.173.1550081335394; Wed, 13 Feb 2019 10:08:55 -0800 (PST) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com. [209.85.167.52]) by smtp.gmail.com with ESMTPSA id q3sm3889659lff.42.2019.02.13.10.08.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 10:08:53 -0800 (PST) Received: by mail-lf1-f52.google.com with SMTP id h10so2282210lfc.12 for ; Wed, 13 Feb 2019 10:08:52 -0800 (PST) X-Received: by 2002:a19:911c:: with SMTP id t28mr1137087lfd.78.1550081331399; Wed, 13 Feb 2019 10:08:51 -0800 (PST) MIME-Version: 1.0 References: <20190211141827.214852402@linuxfoundation.org> <20190211141841.367111122@linuxfoundation.org> <1eb319822aa9f75f423a7790e78315e7672036b9.camel@nokia.com> <20190213131333.GT32494@hirez.programming.kicks-ass.net> In-Reply-To: <20190213131333.GT32494@hirez.programming.kicks-ass.net> From: Linus Torvalds Date: Wed, 13 Feb 2019 10:08:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4.14 198/205] perf/core: Dont WARN() for impossible ring-buffer sizes To: Peter Zijlstra Cc: "Rantala, Tommi T. (Nokia - FI/Espoo)" , "linux-kernel@vger.kernel.org" , "gregkh@linuxfoundation.org" , "mingo@kernel.org" , "jolsa@redhat.com" , "tglx@linutronix.de" , "stable@vger.kernel.org" , "namhyung@kernel.org" , "mark.rutland@arm.com" , "acme@redhat.com" , "alexander.shishkin@linux.intel.com" , "julien.thierry@arm.com" Content-Type: text/plain; charset="UTF-8" Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Wed, Feb 13, 2019 at 5:13 AM Peter Zijlstra wrote: > > There is this queued: > > http://lkml.kernel.org/r/tip-528871b456026e6127d95b1b2bd8e3a003dc1614@git.kernel.org I think it would likely have been better to just remove the test entirely, and instead just use __GFP_NOWARN. This is an allocation essentially done for the user (as part of mmap(), and we handle the failure case fine. So it doesn't matter whether the warning is due to being out of memory or being a bad size, we shouldn't cause a kernel warning. That said, I think we should *indepdendently* have some sane limit for "nr_pages", simply because we do that ... for (i = 0; i < nr_pages; i++) { rb->data_pages[i] = perf_mmap_alloc_page(cpu); thing, which is really really expensive when "nr_pages" is in the thousands (or millions). The fact that we end up almost _accidentally_ limiting nr_pages simply because the kzmalloc() size is limited is I think a mistake. So I'd rather see __GFP_NORWARN _and_ some kind of "don't allow crazy perf ring buffers" check that is separate and independent from any kmalloc issue.. For example, right now the maximum size you can allocate is (insanely) tied to the page size. With a bigger page size, not only do you get a bigger ring buffer anyway, but you also get more 'nr_pages', so it's basically quadratic behavior. Does that make sense? It doesn't sound that way to me. Linus