From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbg154.qq.com (smtpbg154.qq.com [15.184.224.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 852421487E2; Wed, 3 Apr 2024 12:52:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=15.184.224.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148746; cv=none; b=BNVn0gf2GUNknez4y8t/5i5rgRSb6evMEulrAh49Yk2Q/6XfYr7fUv1Thn2JuAO8cByBG9Eluuwz63+a11wtvHoc2V1ZQcsKzlG5B7DXnIrETcOJxMmRkVUCSlJO2esYVgQmtzPAFtecIjzW8quoWcs8KO+TF6Zwm5L1JFnapOQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148746; c=relaxed/simple; bh=Re5TwhQ0QoFy44j2poIlImy55nEU9kHehFfmXVKdsDQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=dzBNhthfzDPy9q/OQHVsGGKxh49AYhAYo73wnOfvjR3JFqIJKiVW1CoFuL0kx7uauIp8pVcvdCL9kb/PrIo0McNzAi9qEXUkZs8tNzzFNnXsYaYMa5kUoxcPZSNhzJd1cCSVOrfA6U3FWNwmwCptWhcufTHOcpdbq4XIEp1YP6Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=15.184.224.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtpsz4t1712148701tsac26x X-QQ-Originating-IP: Pt3Yzg7Fbd/Gq685Lb68nVVJ5dOnwjDPocHW6PLILm8= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:51:39 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: Xz3VOcA7Mr3qdnC/UgwbBFEKd4PF3FRiz2wwJAjHOmXtauSBj/BAFRR5iv1FC vbqv1f5u4tnBbrG136Dyf8/U5jg+rC/llOC07zNbsyMfxXY07N+9nty6ZLdkQixx9ZlQqsR AWONM/ELyb/LOfBuuBStJ/Nebx8w/6VobWY5krrR6xslz8gvqVAquEhzanFmdj6fXo2ul8l WzAldMgUY72gyEQBSBdaEbiu6/0Kyat4hVoVcn+zhaNoCmr9pOWT87sStFgwjbnQp0o9jbl IrL/+lzKAjduNhaU8WzasgQ+gs+gVVxAt4OtbceTOJDCLbBJe8KNx2g+UNYi3dh+NYPe67O mp8jSDvKhnw1uGVs8YeVbQNbcrcFLGVXyubNXumlfmP7xiuwqTqOEktb6UExky/pt90IeYB cg96CN/Wg3BOs3IDP4dbPpAinEn71ejy X-QQ-GoodBg: 2 X-BIZMAIL-ID: 4473137723865551747 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Thomas Gleixner , Andrew Morton , Peter Zijlstra , Rusty Russell , Dawei Li Subject: [PATCH v2 01/10] cpumask: add cpumask_any_and_but() Date: Wed, 3 Apr 2024 20:51:00 +0800 Message-Id: <20240403125109.2054881-2-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpsz:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" From: Mark Rutland In some cases, it's useful to be able to select a random cpu from the intersection of two masks, excluding a particular CPU. For example, in some systems an uncore PMU is shared by a subset of CPUs, and management of this PMU is assigned to some arbitrary CPU in this set. Whenever the management CPU is hotplugged out, we wish to migrate responsibility to another arbitrary CPU which is both in this set and online. Today we can use cpumask_any_and() to select an arbitrary CPU in the intersection of two masks. We can also use cpumask_any_but() to select any arbitrary cpu in a mask excluding, a particular CPU. To do both, we either need to use a temporary cpumask, which is wasteful, or use some lower-level cpumask helpers, which can be unclear. This patch adds a new cpumask_any_and_but() to cater for these cases. Signed-off-by: Mark Rutland Cc: Thomas Gleixner Cc: Andrew Morton Cc: Peter Zijlstra Cc: Rusty Russell Cc: linux-kernel@vger.kernel.org Signed-off-by: Dawei Li --- include/linux/cpumask.h | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h index 1c29947db848..121f3ac757ff 100644 --- a/include/linux/cpumask.h +++ b/include/linux/cpumask.h @@ -388,6 +388,29 @@ unsigned int cpumask_any_but(const struct cpumask *mas= k, unsigned int cpu) return i; } =20 +/** + * cpumask_any_and_but - pick a "random" cpu from *mask1 & *mask2, but not= this one. + * @mask1: the first input cpumask + * @mask2: the second input cpumask + * @cpu: the cpu to ignore + * + * Returns >=3D nr_cpu_ids if no cpus set. + */ +static inline +unsigned int cpumask_any_and_but(const struct cpumask *mask1, + const struct cpumask *mask2, + unsigned int cpu) +{ + unsigned int i; + + cpumask_check(cpu); + i =3D cpumask_first_and(mask1, mask2); + if (i !=3D cpu) + return i; + + return cpumask_next_and(cpu, mask1, mask2); +} + /** * cpumask_nth - get the Nth cpu in a cpumask * @srcp: the cpumask pointer --=20 2.27.0 From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbg150.qq.com (smtpbg150.qq.com [18.132.163.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 575F61487C4; Wed, 3 Apr 2024 12:53:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.132.163.193 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148807; cv=none; b=OMupfjbCDPorgiz24xigQUug8DFx8+7Kn/r+GLiVaQWRALs/56aehukwcYiFaedhkem37uHPuK95jB/jS730ztJHun7N29Nye3vtyw9mROdgu4dMd68r+vOFsfzF5xCt9lV+zfpDx74A5E2ykPzkbi/sQW3W6IK/xi/r2CTY9Oc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148807; c=relaxed/simple; bh=ND5sQn5AjH0gDPbniVnc+41oWPSZKhZ2+RSnBwR/Fts=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=B6eT2E99gPEnaXb+vYyqdBGYqxOfZX6EGHZEmsDvxv6H+Ln8hOMOHomOw/LINAYNE5uG0n5qIFdXoP4Xdv/ramL/6SitGkKDkjt8EEyl9zETp9FO6YPoFO2dgcU/5+5gS6QVQYidMDJZTs8sQlVmmtK0eKMSwQb5HlY9d9CFAwk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=18.132.163.193 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtp85t1712148720twwg6aua X-QQ-Originating-IP: 30EARy7HPLustGG8zN6V2G7XFr0eATYLgWtd0FyeGf4= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:51:59 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: +ynUkgUhZJkgUFfCe2bZDZl3Ri73/Gulvgj5ReUjIICIsO+wcseceAglPbjLH 3PHvR2DU4av5Yr2xF58cto1I4u6+5S8iL319QcXUZRbWHkEih/Q9u4Lac2fFbYySwtR/DhG SVEfS/UgL34ApymCot4ec+R198/YtQ8nsHRJXWk3Zq4Bwew7sFkfrDWeWcqCZbo0cUI9W6y cdt31EdW1zWFapPt4FTc3MmfFkcgrUG/LfS8yVZoySp/fssPUhv1oNBjBpshNsNq392kVq5 IttFr+KOOAJimM/vM0VmzEbwRYjMMQBWDiehgT4Qhpt3xadGhZQH5mLQDGeeRqxSsi/EfMh eaOiBP+db83941cZTmV5YX/rYWRyK83ISKUzqM0qPCQPzxOM6BEpbhVXlH501arQf3aCLYT feip3C/29R/9J/1FJldJOTNiAub3MPIj X-QQ-GoodBg: 2 X-BIZMAIL-ID: 8084547237473899834 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Dawei Li Subject: [PATCH v2 02/10] perf/alibaba_uncore_drw: Avoid placing cpumask var on stack Date: Wed, 3 Apr 2024 20:51:01 +0800 Message-Id: <20240403125109.2054881-3-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" For CONFIG_CPUMASK_OFFSTACK=3Dy kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. But dynamic allocation in cpuhp's teardown callback is somewhat problematic for if allocation fails(which is unlikely but still possible): - If -ENOMEM is returned to caller, kernel crashes for non-bringup teardown; - If callback pretends nothing happened and returns 0 to caller, it may trap system into an in-consisitent/compromised state; Use newly-introduced cpumask_any_and_but() to address all issues above. It eliminates usage of temporary cpumask var in generic way, no matter how the cpumask var is allocated. Suggested-by: Mark Rutland Signed-off-by: Dawei Li Reviewed-by: Mark Rutland --- drivers/perf/alibaba_uncore_drw_pmu.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_u= ncore_drw_pmu.c index a9277dcf90ce..d4d14b65c4a5 100644 --- a/drivers/perf/alibaba_uncore_drw_pmu.c +++ b/drivers/perf/alibaba_uncore_drw_pmu.c @@ -746,18 +746,14 @@ static int ali_drw_pmu_offline_cpu(unsigned int cpu, = struct hlist_node *node) struct ali_drw_pmu_irq *irq; struct ali_drw_pmu *drw_pmu; unsigned int target; - int ret; - cpumask_t node_online_cpus; =20 irq =3D hlist_entry_safe(node, struct ali_drw_pmu_irq, node); if (cpu !=3D irq->cpu) return 0; =20 - ret =3D cpumask_and(&node_online_cpus, - cpumask_of_node(cpu_to_node(cpu)), cpu_online_mask); - if (ret) - target =3D cpumask_any_but(&node_online_cpus, cpu); - else + target =3D cpumask_any_and_but(cpumask_of_node(cpu_to_node(cpu)), + cpu_online_mask, cpu); + if (target >=3D nr_cpu_ids) target =3D cpumask_any_but(cpu_online_mask, cpu); =20 if (target >=3D nr_cpu_ids) --=20 2.27.0 From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbgbr1.qq.com (smtpbgbr1.qq.com [54.207.19.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D1914146D41; Wed, 3 Apr 2024 12:53:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.207.19.206 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148826; cv=none; b=ueKCy4iJPGJ7uJnL4jRcUMAlJIQwti4Fr1U704plMs27Ud8kvDdoI/+hKkF6yXTlAiJbvvKtZTRcSCK5n9mPVg8abNiAuPbLarAGTVmNoxSNSxeJkNvHckfxP52KgnRpua5hqUgcKq5IqzD3IuGdSLXGrzTZ0WkvKNRcpYqpTi8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148826; c=relaxed/simple; bh=N3+jmIFBH0AMFXfes14ZXbK3viT/FuJyr71Pf7bRYZ4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=NzbgNJWejMgm4lOc+PHgtOr9JHkxNFK1jqfH7/5fw1KaKy7l1DjCAKcu8v/MdZUFrMXxQZVrKiMsb80u/4Ym9PHPwnTnlIViUgokfpYF4EHYgU9KZFDDcTEOPhu+7n8V4x0L4W7BsS35QG7WMX4hEFkXTjDhQPFYwCHapyq1T50= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=54.207.19.206 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtpsz15t1712148732tmp3f7 X-QQ-Originating-IP: hp+qVMYBYDmNau3Xt2Ytvj+o84IW5qbOYg/vMTzRtwI= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:52:10 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: RrZlkntZBfm1BsuX7v8GUrYbIkXGb4KuNkFygyd4NSEyO16QA+4WGckn64RjL GQFe6dzbLRg7F9sTRNLUVBLFrP0rvndGl/KOt+YRefEqq0HIn54Nplviah+iU0q6GSWbAiD pqeN4oYni807Hlr+46rlinuWIzRgTDL7fVUzFfxltUv7p2S8/oFTKU3Ffrg4sqJ6WWEcO8k r+R/hy/qxUpId1vFasEipX+0GrflA4/30UbqmZlOmg1fNjf9v8bqI4/Xq8KjOTPQqVuefPj dVAn1+gr/nNR/cMYm4sQimsog4nuA2iK19IglEXwpv/IndcFXiqcTKxYvEO0SZ5eQDycOyD w8qI54wY5oChA3Cjnv/PrqAW4VXkXOpRHF62e7My9Zjh0Ezr4EeYac5ZhxuzRyEh8pOP5Ja uEYnDh0vp5Ribc1zi9ZB1bNKIdKO4Y2B X-QQ-GoodBg: 2 X-BIZMAIL-ID: 4140137453108644267 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Dawei Li Subject: [PATCH v2 03/10] perf/arm-cmn: Avoid placing cpumask var on stack Date: Wed, 3 Apr 2024 20:51:02 +0800 Message-Id: <20240403125109.2054881-4-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpsz:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" For CONFIG_CPUMASK_OFFSTACK=3Dy kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. But dynamic allocation in cpuhp's teardown callback is somewhat problematic for if allocation fails(which is unlikely but still possible): - If -ENOMEM is returned to caller, kernel crashes for non-bringup teardown; - If callback pretends nothing happened and returns 0 to caller, it may trap system into an in-consisitent/compromised state; Use newly-introduced cpumask_any_and_but() to address all issues above. It eliminates usage of temporary cpumask var in generic way, no matter how the cpumask var is allocated. Suggested-by: Mark Rutland Signed-off-by: Dawei Li Reviewed-by: Mark Rutland --- drivers/perf/arm-cmn.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c index 7ef9c7e4836b..6bfb0c4a1287 100644 --- a/drivers/perf/arm-cmn.c +++ b/drivers/perf/arm-cmn.c @@ -1950,20 +1950,20 @@ static int arm_cmn_pmu_offline_cpu(unsigned int cpu= , struct hlist_node *cpuhp_no struct arm_cmn *cmn; unsigned int target; int node; - cpumask_t mask; =20 cmn =3D hlist_entry_safe(cpuhp_node, struct arm_cmn, cpuhp_node); if (cpu !=3D cmn->cpu) return 0; =20 node =3D dev_to_node(cmn->dev); - if (cpumask_and(&mask, cpumask_of_node(node), cpu_online_mask) && - cpumask_andnot(&mask, &mask, cpumask_of(cpu))) - target =3D cpumask_any(&mask); - else + + target =3D cpumask_any_and_but(cpumask_of_node(node), cpu_online_mask, cp= u); + if (target >=3D nr_cpu_ids) target =3D cpumask_any_but(cpu_online_mask, cpu); + if (target < nr_cpu_ids) arm_cmn_migrate(cmn, target); + return 0; } =20 --=20 2.27.0 From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbgsg2.qq.com (smtpbgsg2.qq.com [54.254.200.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA7531419BA; Wed, 3 Apr 2024 12:53:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.254.200.128 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148828; cv=none; b=XCdBgS1oTOWnIJCgzAgijfUsMb+7wYttsPAZbvVd3cf6ooCSqaWDtnB8FFzqV0raeS/c7GPz0Cm44KgSsGXY88SC81rl22bAaTOzeEcqxqIh4G6II5UYsE83S6aVFrc8jm1HXrJDQvbnD0IB108GN/2v3Uia3aQYbPp4JC9HVPE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148828; c=relaxed/simple; bh=S+gSs3P8kYIhVuA52RH41jqATpZYmqcABCpEPESAl4Q=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=JH6XxvIiJUhawHZ3wFhXjiQPaIoASEIvudkriZ+oupXsyzRyvpGHUodkpBdRN7+omNb0vfxDRwHH/PDKp+HSbtq9viCTCICh8+/NRPsDA+6arl08PkT5Aj/6j6lXPBSwshYGkO0imfUd1EMUUWWECxBv8Qhg1veYivVdA7uKNZM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=54.254.200.128 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtpsz13t1712148739t33bir X-QQ-Originating-IP: /irmT9DMA2SI2O2WlAVGo2CSYyzhlc/q+/tf3r54I/g= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:52:17 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: aEYUFldOyMpnMPufkNBznPS4Aas2kZA5zBLS7tmWS34PWtWpMkn9hhp62fMs+ qv79+3DP+69PQTlQfkAgQY0ED7wBXqqh3Ar1lXvmOJMve/vm1qWrNPyYM4+8q0iSB8n7OHM VefijYqxcc3b49cm5Iz1IxuGfG0fd8poD28VHBSga5/1WXiW7+Gkjd+iZ2LYmdYpaGNOJzj VZbWuITnu+Ka3GE8I232wB3OVVTb6aJyj1hukdiaJGYk7rpR5Id3dIT0KjP+/0aNlcl58Oh TLxD3eVy/iNysJ9ozTnipAbOL1p8DhtRoDlq7q6AofO1ISMT+9L7eaZChWE0l8gWjp33Jvr G7QaPMeQU78rTBoIRxTJTu2lKtOalJD7rYBftPhnNU/tbO+SotshjMWhcH/HP7+VSFqf3Yt rFdTt5/SfrKgH2fqHem3lVdUi6bM1u0dLgT7EK+xpzo= X-QQ-GoodBg: 2 X-BIZMAIL-ID: 8095462230992217133 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Dawei Li Subject: [PATCH v2 04/10] perf/arm_cspmu: Avoid placing cpumask var on stack Date: Wed, 3 Apr 2024 20:51:03 +0800 Message-Id: <20240403125109.2054881-5-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpsz:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" For CONFIG_CPUMASK_OFFSTACK=3Dy kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. But dynamic allocation in cpuhp's teardown callback is somewhat problematic for if allocation fails(which is unlikely but still possible): - If -ENOMEM is returned to caller, kernel crashes for non-bringup teardown; - If callback pretends nothing happened and returns 0 to caller, it may trap system into an in-consisitent/compromised state; Use newly-introduced cpumask_any_and_but() to address all issues above. It eliminates usage of temporary cpumask var in generic way, no matter how the cpumask var is allocated. Suggested-by: Mark Rutland Signed-off-by: Dawei Li Reviewed-by: Mark Rutland --- drivers/perf/arm_cspmu/arm_cspmu.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/ar= m_cspmu.c index b9a252272f1e..fd1004251665 100644 --- a/drivers/perf/arm_cspmu/arm_cspmu.c +++ b/drivers/perf/arm_cspmu/arm_cspmu.c @@ -1322,8 +1322,7 @@ static int arm_cspmu_cpu_online(unsigned int cpu, str= uct hlist_node *node) =20 static int arm_cspmu_cpu_teardown(unsigned int cpu, struct hlist_node *nod= e) { - int dst; - struct cpumask online_supported; + unsigned int dst; =20 struct arm_cspmu *cspmu =3D hlist_entry_safe(node, struct arm_cspmu, cpuhp_node); @@ -1333,9 +1332,8 @@ static int arm_cspmu_cpu_teardown(unsigned int cpu, s= truct hlist_node *node) return 0; =20 /* Choose a new CPU to migrate ownership of the PMU to */ - cpumask_and(&online_supported, &cspmu->associated_cpus, - cpu_online_mask); - dst =3D cpumask_any_but(&online_supported, cpu); + dst =3D cpumask_any_and_but(&cspmu->associated_cpus, + cpu_online_mask, cpu); if (dst >=3D nr_cpu_ids) return 0; =20 --=20 2.27.0 From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbgeu1.qq.com (smtpbgeu1.qq.com [52.59.177.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC0771482EC; Wed, 3 Apr 2024 12:53:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=52.59.177.22 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148831; cv=none; b=jdXtfhxornDM5N7ob6xBCleVIOlcAASf8ai9U3Eo5ZSzjOO7kdfnPQ3H4P20X22xRv1yhZQd5Bdi3ew+P8GX/yTudnpbKsn0Qv56I1h5Ze45U9kXuNBLMWOfKlnCam4Yj1GmtQkKJSgPNY+nKLVtROsJeak/7BAGuhMdom+fu7A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148831; c=relaxed/simple; bh=+44ocduMZ3arrVTyEvNGTfJn/pXNlZB4i16mdgLoFoY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=qk/yc9V6ECXRJhb/hXPI9FR0RJ54nFHQtjN0ucKt7xnK54lyXG1XLIIpv6lowKFOk9CsM4c9FRaHHKE3fCucII7Q5x5hgXMxs87O5wpbxUvu8TCs9ojPV9QSLluA+b6M+I1dAs6qyJrwuIsxB8CPS3yw+/OILl47KHRlwBZ7L8U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=52.59.177.22 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtpsz5t1712148745t2zdelq X-QQ-Originating-IP: gtG85rrBFgYquVhBEXaQuedD1lYsKNbDnucmL+QbTUs= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:52:23 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: 3M0okmaRx3hYBn6c6xv94OOmj7QRwjjI90PZMYk07rq6fUKYPq7jtfpesKrxM Hp/NCAse2sa30t5lFPhi4nzJDvtpqAREDZEm9kXuZkZBS54HuzXSTNSOoqy+N7OMGmwZJvB W4N/IGrBxUN2fvl664QjB8Nn2vfTBlWIpxRgfSormkTkhdKMO/jcas8amuGmvm04xhg3JSV GveXZ3D3mDREigPfWnjS+QZuH1I4fZz2QQbba9y4ssVNmO7eka9dFoEPA3d8nZtXlUfC4c6 A/9fdw9FWHqe/O7A13cNIGAhKa/a14mzCAXCc9BTO2seoQFWrVqVRfqFZu8wNV6hlamFZnK SgfFscX3PpNOc+ZCkoVTmrJtTuqoNuht8yQd+/JeuhBz2e9W1wGkyCbwwmommR9Au9KdFWq GQcGDvL6aPh2ZQeszSbdeH0WMml+cW0m X-QQ-GoodBg: 2 X-BIZMAIL-ID: 8972781227681254528 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Dawei Li Subject: [PATCH v2 05/10] perf/arm_dsu: Avoid placing cpumask var on stack Date: Wed, 3 Apr 2024 20:51:04 +0800 Message-Id: <20240403125109.2054881-6-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpsz:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" For CONFIG_CPUMASK_OFFSTACK=3Dy kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. But dynamic allocation in cpuhp's teardown callback is somewhat problematic for if allocation fails(which is unlikely but still possible): - If -ENOMEM is returned to caller, kernel crashes for non-bringup teardown; - If callback pretends nothing happened and returns 0 to caller, it may trap system into an in-consisitent/compromised state; Use newly-introduced cpumask_any_and_but() to address all issues above. It eliminates usage of temporary cpumask var in generic way, no matter how the cpumask var is allocated. Suggested-by: Mark Rutland Signed-off-by: Dawei Li Reviewed-by: Mark Rutland --- drivers/perf/arm_dsu_pmu.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c index bae3ca37f846..adc0bbb5fafe 100644 --- a/drivers/perf/arm_dsu_pmu.c +++ b/drivers/perf/arm_dsu_pmu.c @@ -230,15 +230,6 @@ static const struct attribute_group *dsu_pmu_attr_grou= ps[] =3D { NULL, }; =20 -static int dsu_pmu_get_online_cpu_any_but(struct dsu_pmu *dsu_pmu, int cpu) -{ - struct cpumask online_supported; - - cpumask_and(&online_supported, - &dsu_pmu->associated_cpus, cpu_online_mask); - return cpumask_any_but(&online_supported, cpu); -} - static inline bool dsu_pmu_counter_valid(struct dsu_pmu *dsu_pmu, u32 idx) { return (idx < dsu_pmu->num_counters) || @@ -827,14 +818,16 @@ static int dsu_pmu_cpu_online(unsigned int cpu, struc= t hlist_node *node) =20 static int dsu_pmu_cpu_teardown(unsigned int cpu, struct hlist_node *node) { - int dst; - struct dsu_pmu *dsu_pmu =3D hlist_entry_safe(node, struct dsu_pmu, - cpuhp_node); + struct dsu_pmu *dsu_pmu; + unsigned int dst; + + dsu_pmu =3D hlist_entry_safe(node, struct dsu_pmu, cpuhp_node); =20 if (!cpumask_test_and_clear_cpu(cpu, &dsu_pmu->active_cpu)) return 0; =20 - dst =3D dsu_pmu_get_online_cpu_any_but(dsu_pmu, cpu); + dst =3D cpumask_any_and_but(&dsu_pmu->associated_cpus, + cpu_online_mask, cpu); /* If there are no active CPUs in the DSU, leave IRQ disabled */ if (dst >=3D nr_cpu_ids) return 0; --=20 2.27.0 From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbguseast3.qq.com (smtpbguseast3.qq.com [54.243.244.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C18E7146A9D; Wed, 3 Apr 2024 12:54:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.243.244.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148867; cv=none; b=Yme7K/fLW41G6ovto5zi7zID1tuJO86HkhnxxsOke9cDVMfHhWRy3emspl4V3AS9F6i562s8X0DjLeWvWz5yL8GLTiFKOoDmeII6UO2KaJMxrC35jRz3derOVNk6XgkUatrcUbOSQiL7s9p/owoMVdQj4NUEj067CTWvq2ES6XY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148867; c=relaxed/simple; bh=DuvQOR4vsP78Wm5NVq8AOQUFUfQcm9T0pyka2X4Hhp4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Vq6wcXB8KZAtZJJN81wkzoGEFfLLDgjH0XHVU6MHPoRm9klc7lthG1QFd5ud4Rlu4lgdSXfrY1//AE9ZYGCngow4gWKsHYp4lFKM9++8wD8gf+3Kd3WAbuQf5aqsz7JyV/NtEP+ituFXmEUue0QMrxhQl0GROVWYwU2mLFO5yCg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=54.243.244.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtpsz13t1712148751thjp14 X-QQ-Originating-IP: PN96WD6+s0f0fHNZoIaqwlrHcfY0nVQajJhi8FUfFuM= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:52:30 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: zcLa5zqvhxgf/5JXWZ8twfXFCazlSAsrySVLuhjEZMYToUkKWNsAJmBBYfDe+ NsLkXC+chAgf1GKnj0xs+cjveEn376+2q5jqMLFhczeZpSps2N19LEoRD2EbL4GsthwKh2A ZyAM+BPRilAQekCh1hGwcIFu4x73e4p44a+fel0VgLqjLCpdTtAIDgjrdSd5diS1y57wy88 hDyTUongOVf12A2X/IV7LhSD94AniI9zUmfBXtROAXHdcHcYaWhLWsEoBZGrY2TnkpQM+My W/ls2X2G2eB/4CVV13mfkN8eKhXbh+2+EZslaoWjqF2Vpw/mamsDazphJq5suJJVWI/apJG AD/bzvFButsgFqs8fNhD38vhGupDFjLpN6Juab9D/+ynsLdXRwsXrr+Bl9JrApdbDjgOxeM oLfxxIRlYsInBfAA6uV2dWzExTT2ldHB X-QQ-GoodBg: 2 X-BIZMAIL-ID: 11098512972322688443 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Dawei Li Subject: [PATCH v2 06/10] perf/dwc_pcie: Avoid placing cpumask var on stack Date: Wed, 3 Apr 2024 20:51:05 +0800 Message-Id: <20240403125109.2054881-7-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpsz:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" For CONFIG_CPUMASK_OFFSTACK=3Dy kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. But dynamic allocation in cpuhp's teardown callback is somewhat problematic for if allocation fails(which is unlikely but still possible): - If -ENOMEM is returned to caller, kernel crashes for non-bringup teardown; - If callback pretends nothing happened and returns 0 to caller, it may trap system into an in-consisitent/compromised state; Use newly-introduced cpumask_any_and_but() to address all issues above. It eliminates usage of temporary cpumask var in generic way, no matter how the cpumask var is allocated. Suggested-by: Mark Rutland Signed-off-by: Dawei Li Reviewed-by: Mark Rutland --- drivers/perf/dwc_pcie_pmu.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/perf/dwc_pcie_pmu.c b/drivers/perf/dwc_pcie_pmu.c index 957058ad0099..c5e328f23841 100644 --- a/drivers/perf/dwc_pcie_pmu.c +++ b/drivers/perf/dwc_pcie_pmu.c @@ -690,9 +690,8 @@ static int dwc_pcie_pmu_offline_cpu(unsigned int cpu, s= truct hlist_node *cpuhp_n { struct dwc_pcie_pmu *pcie_pmu; struct pci_dev *pdev; - int node; - cpumask_t mask; unsigned int target; + int node; =20 pcie_pmu =3D hlist_entry_safe(cpuhp_node, struct dwc_pcie_pmu, cpuhp_node= ); /* Nothing to do if this CPU doesn't own the PMU */ @@ -702,10 +701,9 @@ static int dwc_pcie_pmu_offline_cpu(unsigned int cpu, = struct hlist_node *cpuhp_n pcie_pmu->on_cpu =3D -1; pdev =3D pcie_pmu->pdev; node =3D dev_to_node(&pdev->dev); - if (cpumask_and(&mask, cpumask_of_node(node), cpu_online_mask) && - cpumask_andnot(&mask, &mask, cpumask_of(cpu))) - target =3D cpumask_any(&mask); - else + + target =3D cpumask_any_and_but(cpumask_of_node(node), cpu_online_mask, cp= u); + if (target >=3D nr_cpu_ids) target =3D cpumask_any_but(cpu_online_mask, cpu); =20 if (target >=3D nr_cpu_ids) { --=20 2.27.0 From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbg154.qq.com (smtpbg154.qq.com [15.184.224.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A8A214F613; Wed, 3 Apr 2024 12:54:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=15.184.224.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148856; cv=none; b=aggEJW+tGuEEgnFDymsGJnMiu2GvVHM8ZaoQ5chr6t9KndWKjmg25XqnujVOpNSgQyOChhSnncnOtDZcKR7+m9J18OIn5JVwmchF+BvoWIrOs+/NT7fA94TPC8cuimDg7PvVrWSmtleB5c5M+LbtJBLwy5UHExbQxQMrzwST9Xw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148856; c=relaxed/simple; bh=eD3mfKYgc+nRUPkrE3ZTzbALwXtkGiDfBxjh0ZWxoIU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=XuA2ugI9STldshcrKDQcoUbFUOaeX2nfG8Zcxx5puFNBFG2bc/DKubvxzsXO9wHJ8MRN2YiSf2YaJ1FQqXoz7FsbZn3eZJdVygSu2B2P6Bcftc79+POzcIs8Wqj6mpeZqele5xOVdZlTWXjPCl7nDSEb3aSLei+9BqES0VFHVTk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=15.184.224.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtpsz14t1712148757trdpo7 X-QQ-Originating-IP: DSTvJb15+fliyf2zWUZJBYnhPlXY5kA800cxsWCzZAk= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:52:36 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: DoD8xN2rKoyVx7iKxegRViP9yMHQO4PaK1xU/ZRFnWvi6EHTmFXXoEI0Tq+YG VGPFDOfLxJqbT+UZl66iAoaeAMjri+NbDF9MK+kIvkjGPQu5hREf2A4wLewIUWa5U7TNPVf vSDKXMrntzyaD6bwhCpjQiIPt2Rtz+gxZRQnirHyzS/Lz3XfECT1b902pBjGETAHk+t5qp5 DILh6DAT2KGSocqoB4sJWqzKV0DB4YcD4ObXhuKmANDEkGX7yrae25xH7MV8443POuc0gYP wFtLo4KuUmtHU2GlaaqqHmRsYYJa360fBY4jnCVDfGkSh5NSP/Z9q3m0aKWGamL4BZKY/WG iqFFIoZ/4qTBWDH5G7aez/K0eOcIN6qjoohy70tTEsOWkSuqey5Kmata83VI9Ox9Ijj0J2H 79lmb0hIr7MukC8G8+W7D4iY7ei5TGnN X-QQ-GoodBg: 2 X-BIZMAIL-ID: 15651604539771351507 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Dawei Li Subject: [PATCH v2 07/10] perf/hisi_pcie: Avoid placing cpumask var on stack Date: Wed, 3 Apr 2024 20:51:06 +0800 Message-Id: <20240403125109.2054881-8-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpsz:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" For CONFIG_CPUMASK_OFFSTACK=3Dy kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. But dynamic allocation in cpuhp's teardown callback is somewhat problematic for if allocation fails(which is unlikely but still possible): - If -ENOMEM is returned to caller, kernel crashes for non-bringup teardown; - If callback pretends nothing happened and returns 0 to caller, it may trap system into an in-consisitent/compromised state; Use newly-introduced cpumask_any_and_but() to address all issues above. It eliminates usage of temporary cpumask var in generic way, no matter how the cpumask var is allocated. Suggested-by: Mark Rutland Signed-off-by: Dawei Li Acked-by: Jonathan Cameron Reviewed-by: Mark Rutland --- drivers/perf/hisilicon/hisi_pcie_pmu.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/perf/hisilicon/hisi_pcie_pmu.c b/drivers/perf/hisilico= n/hisi_pcie_pmu.c index 5d1f0e9fdb08..06b192cc31d5 100644 --- a/drivers/perf/hisilicon/hisi_pcie_pmu.c +++ b/drivers/perf/hisilicon/hisi_pcie_pmu.c @@ -673,7 +673,6 @@ static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, = struct hlist_node *node) { struct hisi_pcie_pmu *pcie_pmu =3D hlist_entry_safe(node, struct hisi_pci= e_pmu, node); unsigned int target; - cpumask_t mask; int numa_node; =20 /* Nothing to do if this CPU doesn't own the PMU */ @@ -684,10 +683,10 @@ static int hisi_pcie_pmu_offline_cpu(unsigned int cpu= , struct hlist_node *node) =20 /* Choose a local CPU from all online cpus. */ numa_node =3D dev_to_node(&pcie_pmu->pdev->dev); - if (cpumask_and(&mask, cpumask_of_node(numa_node), cpu_online_mask) && - cpumask_andnot(&mask, &mask, cpumask_of(cpu))) - target =3D cpumask_any(&mask); - else + + target =3D cpumask_any_and_but(cpumask_of_node(numa_node), + cpu_online_mask, cpu); + if (target >=3D nr_cpu_ids) target =3D cpumask_any_but(cpu_online_mask, cpu); =20 if (target >=3D nr_cpu_ids) { --=20 2.27.0 From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbguseast1.qq.com (smtpbguseast1.qq.com [54.204.34.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98AFC148841; Wed, 3 Apr 2024 12:54:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.204.34.129 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148872; cv=none; b=etdSqiokWwlHIkc14jXmIONFQTyH7lH+wISD5R3i5SCbTiToQloK3XnLhaWIUl7fhcqvpxRXoEXXtMHlm+VpjS65sHL+aU3hG6SOUX18Xjl0PQUVuFGXzpY4BTMs6lKHKktZQkgniyabkBs/J53FzVKNjTajF0ZnKkPGr80eVFo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148872; c=relaxed/simple; bh=PbJpsS6QV6+Tp3EXxgnNlfow6jJ418jVf9NSjPKQhoA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=cAkdkJ6z3aSVjZAb9CsokNIYd5BZNGl+3LLjaGhy/we1Hhk7sRNBK++YFsHnAJQWAyDhB6qPs9c+l/oJFGLuFt5IZsGrFmyspkZtMTy1sw5nWf5DKbQvNXFRV7sd4Va2c8rZe+g37CrjLY7DLw9xCWsx3AA2PR0xyaTHAqy+nQ4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=54.204.34.129 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtpsz1t1712148769tl9mcxo X-QQ-Originating-IP: 7CdYVYVG2lr2tEe8hqubrWolD6g2IXhFkGfHpfc1Z0U= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:52:48 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: y5UFFkuhlmKejcdNDiyPEy64+ZXAkB4rPf1NixYuJI1SXyXDlruyNpd1pFpL3 jqEY/qff9Bm7byyGiXyXEFxIqzzNDAaoKAc5bTsV7M5PeaDXwSWFpCdZGrOciKiEX71G/oA bvvQjNPJzBYtAIIpPv83YOE8tBIIM87ny5yDiiuGwc8VSrlhYpqzhrYDs5rGhHhEbFwC7F8 WbAcUgLi/O80xmeiX9SAQtUGb2as5pv/+gxJuTesuLpZkatZDgBVHlD9ruI+5WvZiMTLAjB 7azxBO+RrcKlZo5iedTqWWeFG/UiGXEONRoAQJiYXF6xCR+ExdBuXuplaqwOVw54NSOYyTT HZaadLo6vy75jPpbVRtg3z1oN/SmkvlrwQrWrK5uF7un+AQMh+LuffRffPy/+InRlhsb31q M6IezlmJOHxAITAwhuAxEGeS5qll5p0R X-QQ-GoodBg: 2 X-BIZMAIL-ID: 12696791724111325395 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Dawei Li Subject: [PATCH v2 08/10] perf/hisi_uncore: Avoid placing cpumask var on stack Date: Wed, 3 Apr 2024 20:51:07 +0800 Message-Id: <20240403125109.2054881-9-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpsz:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" For CONFIG_CPUMASK_OFFSTACK=3Dy kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. But dynamic allocation in cpuhp's teardown callback is somewhat problematic for if allocation fails(which is unlikely but still possible): - If -ENOMEM is returned to caller, kernel crashes for non-bringup teardown; - If callback pretends nothing happened and returns 0 to caller, it may trap system into an in-consisitent/compromised state; Use newly-introduced cpumask_any_and_but() to address all issues above. It eliminates usage of temporary cpumask var in generic way, no matter how the cpumask var is allocated. Suggested-by: Mark Rutland Signed-off-by: Dawei Li Acked-by: Jonathan Cameron Reviewed-by: Mark Rutland --- drivers/perf/hisilicon/hisi_uncore_pmu.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c b/drivers/perf/hisili= con/hisi_uncore_pmu.c index 04031450d5fe..ccc9191ad1b6 100644 --- a/drivers/perf/hisilicon/hisi_uncore_pmu.c +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c @@ -504,7 +504,6 @@ int hisi_uncore_pmu_offline_cpu(unsigned int cpu, struc= t hlist_node *node) { struct hisi_pmu *hisi_pmu =3D hlist_entry_safe(node, struct hisi_pmu, node); - cpumask_t pmu_online_cpus; unsigned int target; =20 if (!cpumask_test_and_clear_cpu(cpu, &hisi_pmu->associated_cpus)) @@ -518,9 +517,8 @@ int hisi_uncore_pmu_offline_cpu(unsigned int cpu, struc= t hlist_node *node) hisi_pmu->on_cpu =3D -1; =20 /* Choose a new CPU to migrate ownership of the PMU to */ - cpumask_and(&pmu_online_cpus, &hisi_pmu->associated_cpus, - cpu_online_mask); - target =3D cpumask_any_but(&pmu_online_cpus, cpu); + target =3D cpumask_any_and_but(&hisi_pmu->associated_cpus, + cpu_online_mask, cpu); if (target >=3D nr_cpu_ids) return 0; =20 --=20 2.27.0 From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbgau2.qq.com (smtpbgau2.qq.com [54.206.34.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F667148841; Wed, 3 Apr 2024 12:54:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.206.34.216 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148878; cv=none; b=DPGm7ed+xBgVUMAWKb2LS+axm7uTaRZILNajLawIi4VbIj+/a7xhtuwPrnFZLI7eIh5p17FNiKpaLthzeVUUqN10dCnID7shnLBct/TuYgJOYv8cxs9Ll7PLxsIMAN1J1MggVzd7cCtYgP+pG08URx8zRTv3H2sLv0awMtatQpA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148878; c=relaxed/simple; bh=YPbYnG00R6gzJY3wQosCsmzl+ZE2k9Rcp+wAlH+Q/vQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=KqCC14rph7n3a/navJUIStgHlsyCRizq3WyV3sDU+RRYvZHvZ2sXDUWQ1GZpUc4DDmfIpdiGFnNl+JXgZSBqcmWd2dEFCBoVZ3gtI4hZ8PLsA63obxnG94TnIzrShmI4HPYUmj0PVQ9bj/Td0Ey7v5JG9fOrA0x439TwEjNnIhk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=54.206.34.216 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtp79t1712148775teye1u3j X-QQ-Originating-IP: xdXNA6zp8ZSrFbbqKwC7auWvxA+9gSLqEpXCtDjvsc8= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:52:54 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: RmQi6iQXyoPI3227xPNYQoydQAD/PwEqenSojQohu5757FSm3x7ceIiKbAVGu 412DzCp1YWMrlYllY6gv9ImMEfEWAD5DsWbtLmD1KDWtDGmFg2aMGLi0Zj5JQVC+1aXtngL u2nerBQMgjZ1JaIt5LAA20jmq5u0EV9XnXuTDItDmDBcZMz4dhmUgaEr7djBrbtW95ZRsN6 2f4bQNLDOB527dcnzaBSi5y/7qjTjHKvftRFlJ8z/GdorcYD1HH7QedXtJNW2Neb7QNAhuz 0hoK/CAOWuZzThYCMs1Hl3aalSKlRTobx5IxOE3giObFjp5Pno08NUN7R6YKJ/M7KoeAmOe m83vrEBDYEwqYIdXMIB/n5acoCF4TyirSZKmSVzR45oKz6Tff4ZyjojIOaUh6Mu1e8xgmpb 27ARI95bBrMpObXtXUtTNG3idfP/MYs+ X-QQ-GoodBg: 2 X-BIZMAIL-ID: 4365670256005717423 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Dawei Li Subject: [PATCH v2 09/10] perf/qcom_l2: Avoid placing cpumask var on stack Date: Wed, 3 Apr 2024 20:51:08 +0800 Message-Id: <20240403125109.2054881-10-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" For CONFIG_CPUMASK_OFFSTACK=3Dy kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. But dynamic allocation in cpuhp's teardown callback is somewhat problematic for if allocation fails(which is unlikely but still possible): - If -ENOMEM is returned to caller, kernel crashes for non-bringup teardown; - If callback pretends nothing happened and returns 0 to caller, it may trap system into an in-consisitent/compromised state; Use newly-introduced cpumask_any_and_but() to address all issues above. It eliminates usage of temporary cpumask var in generic way, no matter how the cpumask var is allocated. Suggested-by: Mark Rutland Signed-off-by: Dawei Li Reviewed-by: Mark Rutland --- drivers/perf/qcom_l2_pmu.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/perf/qcom_l2_pmu.c b/drivers/perf/qcom_l2_pmu.c index 148df5ae8ef8..b5a44dc1dc3a 100644 --- a/drivers/perf/qcom_l2_pmu.c +++ b/drivers/perf/qcom_l2_pmu.c @@ -801,9 +801,8 @@ static int l2cache_pmu_online_cpu(unsigned int cpu, str= uct hlist_node *node) =20 static int l2cache_pmu_offline_cpu(unsigned int cpu, struct hlist_node *no= de) { - struct cluster_pmu *cluster; struct l2cache_pmu *l2cache_pmu; - cpumask_t cluster_online_cpus; + struct cluster_pmu *cluster; unsigned int target; =20 l2cache_pmu =3D hlist_entry_safe(node, struct l2cache_pmu, node); @@ -820,9 +819,8 @@ static int l2cache_pmu_offline_cpu(unsigned int cpu, st= ruct hlist_node *node) cluster->on_cpu =3D -1; =20 /* Any other CPU for this cluster which is still online */ - cpumask_and(&cluster_online_cpus, &cluster->cluster_cpus, - cpu_online_mask); - target =3D cpumask_any_but(&cluster_online_cpus, cpu); + target =3D cpumask_any_and_but(&cluster->cluster_cpus, + cpu_online_mask, cpu); if (target >=3D nr_cpu_ids) { disable_irq(cluster->irq); return 0; --=20 2.27.0 From nobody Sun Jul 12 12:08:01 2026 Received: from smtpbgau2.qq.com (smtpbgau2.qq.com [54.206.34.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8A88E14900F; Wed, 3 Apr 2024 12:54:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.206.34.216 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148889; cv=none; b=OUXBnnmTn9hPCRNj8yv0oE2XW87uo2hb338t/23YAzVurpC+bANO+sA8UPNG1p9PakelgCtwYP6g5UTlgiqMNkh0LW+9W37nvmy8PMPcPlehiIkIoWzZHvHygMcQq6RfvVTLNLGxC0uOz9FBLjA9EBk63Kd71uibf9pIdEVkIG8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712148889; c=relaxed/simple; bh=xXJvc27158uMzeJNX4bgx6mUDVSgnlq9ce9aZe5v3B4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=IlYhUpU2w0C4JRLtPrXLij458ZEHLIltfTx0VH6eDn2MK7D/kDeza49HLXhKmxtppc8Vf8RydM4Ut9udDFOaXUKlbXA06Qd/U3U3J9ghKRYpPFEHIKwsVpnIiGDXqpjHPZlymczP0Gt2TvHlOomqxFzxHWuFm1bEoKmLwQ4KC5Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn; spf=pass smtp.mailfrom=shingroup.cn; arc=none smtp.client-ip=54.206.34.216 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shingroup.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shingroup.cn X-QQ-mid: bizesmtpsz1t1712148785t9jh8zy X-QQ-Originating-IP: glNtj0eRp0IOBFLCOi1CaGqaaEumMkerNThHocu9b+k= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 03 Apr 2024 20:53:04 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: +ynUkgUhZJkR1+2Xpbw3pa6lG4d42cKOBYOKy4eBM/Jbqbkv0AiQwK85DK9n1 983cnBzJioQLx2jW5n10h586uD5pFDBsC+v12PpxJYaKBi3CSH/AmSm88+X9mOQQH8/QZ63 PG3ju17FiN2Dd4TWCF7X1iXJfg63o8upsKBrlHBlhEbSbLEySN06aN/oYGc5jgiBcG8X5Bp 1lABsa0QVpzkBNFCbrjCZcdBy7xoNDq1ADjdWQkMU0CNhITXi0yskRVq33PqVBthi6fTNSt IzpNnzIqNNQRwXPQN80AGwyXXnm3YBgOIxP8o71LF5W4AFOgcKSD/GXhC0ne4Zx83dF2qUs DVPirTGQv4Rbo7GV7MzZpG3r4bkNn+xF135c0YgkOHUZKhO9xWOsAz+OjtOg5jvd7rZuX1h qA68Tfvh8S+vNUKQNWDDAAbW7BaVf2NZ X-QQ-GoodBg: 2 X-BIZMAIL-ID: 17308809335922861107 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk Cc: 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, Dawei Li Subject: [PATCH v2 10/10] perf/thunderx2: Avoid placing cpumask var on stack Date: Wed, 3 Apr 2024 20:51:09 +0800 Message-Id: <20240403125109.2054881-11-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240403125109.2054881-1-dawei.li@shingroup.cn> References: <20240403125109.2054881-1-dawei.li@shingroup.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpsz:shingroup.cn:qybglogicsvrgz:qybglogicsvrgz5a-1 Content-Type: text/plain; charset="utf-8" For CONFIG_CPUMASK_OFFSTACK=3Dy kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. But dynamic allocation in cpuhp's teardown callback is somewhat problematic for if allocation fails(which is unlikely but still possible): - If -ENOMEM is returned to caller, kernel crashes for non-bringup teardown; - If callback pretends nothing happened and returns 0 to caller, it may trap system into an in-consisitent/compromised state; Use newly-introduced cpumask_any_and_but() to address all issues above. It eliminates usage of temporary cpumask var in generic way, no matter how the cpumask var is allocated. Suggested-by: Mark Rutland Signed-off-by: Dawei Li Reviewed-by: Mark Rutland --- drivers/perf/thunderx2_pmu.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c index e16d10c763de..b3377b662ffc 100644 --- a/drivers/perf/thunderx2_pmu.c +++ b/drivers/perf/thunderx2_pmu.c @@ -932,9 +932,8 @@ static int tx2_uncore_pmu_online_cpu(unsigned int cpu, static int tx2_uncore_pmu_offline_cpu(unsigned int cpu, struct hlist_node *hpnode) { - int new_cpu; struct tx2_uncore_pmu *tx2_pmu; - struct cpumask cpu_online_mask_temp; + unsigned int new_cpu; =20 tx2_pmu =3D hlist_entry_safe(hpnode, struct tx2_uncore_pmu, hpnode); @@ -945,11 +944,8 @@ static int tx2_uncore_pmu_offline_cpu(unsigned int cpu, if (tx2_pmu->hrtimer_callback) hrtimer_cancel(&tx2_pmu->hrtimer); =20 - cpumask_copy(&cpu_online_mask_temp, cpu_online_mask); - cpumask_clear_cpu(cpu, &cpu_online_mask_temp); - new_cpu =3D cpumask_any_and( - cpumask_of_node(tx2_pmu->node), - &cpu_online_mask_temp); + new_cpu =3D cpumask_any_and_but(cpumask_of_node(tx2_pmu->node), + cpu_online_mask, cpu); =20 tx2_pmu->cpu =3D new_cpu; if (new_cpu >=3D nr_cpu_ids) --=20 2.27.0