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=-3.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 6DE87CA9EA0 for ; Mon, 4 Nov 2019 11:09:18 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 27E6E21D81 for ; Mon, 4 Nov 2019 11:09:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27E6E21D81 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 47696M3KzXzF4jk for ; Mon, 4 Nov 2019 22:09:15 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=rjwysocki.net (client-ip=79.96.170.134; helo=cloudserver094114.home.pl; envelope-from=rjw@rjwysocki.net; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=rjwysocki.net Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 47693v0T8WzF214 for ; Mon, 4 Nov 2019 22:07:05 +1100 (AEDT) Received: from 79.184.254.83.ipv4.supernova.orange.pl (79.184.254.83) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.292) id 2c11b88dbf4206f5; Mon, 4 Nov 2019 12:07:00 +0100 From: "Rafael J. Wysocki" To: John Hubbard Subject: Re: [PATCH v3] cpufreq: powernv: fix stack bloat and hard limit on num cpus Date: Mon, 04 Nov 2019 12:06:59 +0100 Message-ID: <8351130.8dpKiuZLPc@kreacher> In-Reply-To: <20191031052159.4125031-1-jhubbard@nvidia.com> References: <20191031052159.4125031-1-jhubbard@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-pm@vger.kernel.org, LKML , Shilpasri G Bhat , Viresh Kumar , Preeti U Murthy , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thursday, October 31, 2019 6:21:59 AM CET John Hubbard wrote: > The following build warning occurred on powerpc 64-bit builds: > > drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': > drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of > 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] > > This is with a cross-compiler based on gcc 8.1.0, which I got from: > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ > > The warning is due to putting 1024 bytes on the stack: > > unsigned int chip[256]; > > ...and it's also undesirable to have a hard limit on the number of > CPUs here. > > Fix both problems by dynamically allocating based on num_possible_cpus, > as recommended by Michael Ellerman. > > Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") > Cc: Michael Ellerman > Cc: Shilpasri G Bhat > Cc: Preeti U Murthy > Cc: Viresh Kumar > Cc: Rafael J. Wysocki > Cc: linux-pm@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: John Hubbard > Acked-by: Viresh Kumar > --- > > Changes since v2: applied fixes from Michael Ellerman's review: > > * Changed from CONFIG_NR_CPUS to num_possible_cpus() > > * Fixed up commit description: added a note about exactly which > compiler generates the warning. And softened up wording about > the limitation on number of CPUs. > > Changes since v1: includes Viresh's review commit fixes. Applying as 5.5 material, thanks!