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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5597ACD1284 for ; Tue, 2 Apr 2024 11:13:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GXazMdmWCHQBCQ7HyAx9NwUTpav27tauxYssnXmmKZg=; b=EOLOro+reDqcgC UkR4IvSI+3d3pt4hJwjesFP7gALkqMSHqvBD6Es4/i6h3r0drluGZLX44SfubIUlCCPo7/gRQIqsk Ey3KjZRtJB0Aa7wiq36Zsd/rD9y5yrAi+YaW97TTWxuskipdTeRLtkFkSiXn5aj0iz5+VGQ8j5pbR +RDGYh2QfnbZw1q7wknOWy+m49ff+1vJnW52//wU2+cSXo7XjmvjXVqwF6wAnNdUPGdE+m8Bds9bu 8A/0b1U0msE1+ZBbzRJkpOnBPKgGYTGEPtSVEyAbhZmFDH5Me/5T5AkCXK/1Vf+HoX9Pvn6BZk6tu mn3e/ElhghQlPtEKSy5Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrc4Z-0000000AozX-1mvf; Tue, 02 Apr 2024 11:12:59 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrc4X-0000000Aoyx-06vQ for linux-arm-kernel@lists.infradead.org; Tue, 02 Apr 2024 11:12:58 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 890FB1007; Tue, 2 Apr 2024 04:13:27 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.18.33]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A0FDA3F766; Tue, 2 Apr 2024 04:12:53 -0700 (PDT) Date: Tue, 2 Apr 2024 12:12:50 +0100 From: Mark Rutland To: Dawei Li Cc: will@kernel.org, xueshuai@linux.alibaba.com, renyu.zj@linux.alibaba.com, yangyicong@hisilicon.com, jonathan.cameron@huawei.com, andersson@kernel.org, konrad.dybcio@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH 0/9] perf: Avoid explicit cpumask var allocation from stack Message-ID: References: <20240402105610.1695644-1-dawei.li@shingroup.cn> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240402_041257_183898_A5594915 X-CRM114-Status: GOOD ( 23.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Apr 02, 2024 at 06:56:01PM +0800, Dawei Li wrote: > Hi, > > This series try to eliminate direct cpumask var allocation from stack > for perf subsystem. > > Direct/explicit allocation of cpumask on stack could be dangerous since > it can lead to stack overflow for systems with big NR_CPUS or > CONFIG_CPUMASK_OFFSTACK=y. > > For arm64, it's more urgent since commit 3fbd56f0e7c1 ("ARM64: Dynamically > allocate cpumasks and increase supported CPUs to 512"). > > It's sort of a pattern that almost every cpumask var in perf subystem > occurs in teardown callback of cpuhp. In which case, if dynamic > allocation failed(which is unlikely), we choose return 0 rather than > -ENOMEM to caller cuz: > @teardown is not supposed to fail and if it does, system crashes: ... but we've left the system in an incorrect state, so that makes no sense. As I commented on the first patch, NAK to dynamically allocating cpumasks in the CPUHP callbacks. Please allocate the necessry cpumasks up-front when we probe the PMU. At that time we can handle an allocation failure by cleaning up and failing to probe the PMU, and then the CPUHP callbacks don't need to allocate memory to offline a CPU... Also, for the titles it'd be better to say something like "avoid placing cpumasks on the stack", because "explicit cpumask var allocation" sounds like the use of alloc_cpumask_var(). Mark. > > static int cpuhp_issue_call(int cpu, enum cpuhp_state state, bool bringup, > struct hlist_node *node) > { > struct cpuhp_step *sp = cpuhp_get_step(state); > int ret; > > /* > * If there's nothing to do, we done. > * Relies on the union for multi_instance. > */ > if (cpuhp_step_empty(bringup, sp)) > return 0; > /* > * The non AP bound callbacks can fail on bringup. On teardown > * e.g. module removal we crash for now. > */ > #ifdef CONFIG_SMP > if (cpuhp_is_ap_state(state)) > ret = cpuhp_invoke_ap_callback(cpu, state, bringup, node); > else > ret = cpuhp_invoke_callback(cpu, state, bringup, node, > NULL); > #else > ret = cpuhp_invoke_callback(cpu, state, bringup, node, NULL); > #endif > BUG_ON(ret && !bringup); > return ret; > } > > Dawei Li (9): > perf/alibaba_uncore_drw: Avoid explicit cpumask var allocation from > stack > perf/arm-cmn: Avoid explicit cpumask var allocation from stack > perf/arm_cspmu: Avoid explicit cpumask var allocation from stack > perf/arm_dsu: Avoid explicit cpumask var allocation from stack > perf/dwc_pcie: Avoid explicit cpumask var allocation from stack > perf/hisi_pcie: Avoid explicit cpumask var allocation from stack > perf/hisi_uncore: Avoid explicit cpumask var allocation from stack > perf/qcom_l2: Avoid explicit cpumask var allocation from stack > perf/thunder_x2: Avoid explicit cpumask var allocation from stack > > drivers/perf/alibaba_uncore_drw_pmu.c | 13 +++++++++---- > drivers/perf/arm-cmn.c | 13 +++++++++---- > drivers/perf/arm_cspmu/arm_cspmu.c | 13 +++++++++---- > drivers/perf/arm_dsu_pmu.c | 18 +++++++++++++----- > drivers/perf/dwc_pcie_pmu.c | 17 +++++++++++------ > drivers/perf/hisilicon/hisi_pcie_pmu.c | 15 ++++++++++----- > drivers/perf/hisilicon/hisi_uncore_pmu.c | 13 +++++++++---- > drivers/perf/qcom_l2_pmu.c | 15 ++++++++++----- > drivers/perf/thunderx2_pmu.c | 20 ++++++++++++-------- > 9 files changed, 92 insertions(+), 45 deletions(-) > > > Thanks, > > Dawei > > -- > 2.27.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel