From nobody Mon Feb 9 12:10:18 2026 Received: from bg1.exmail.qq.com (bg1.exmail.qq.com [114.132.62.65]) (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 CB9F984A35; Tue, 2 Apr 2024 10:58:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=114.132.62.65 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055496; cv=none; b=eXZm6GZv8U24Qa7vn+lHej4F8yck9bI0OZBJ/JZJboWz6uruv+OTY6phfdrWZQ59coMqBlnITYVNQsEhOHvO85AYb43OqT/0o0ck1/MRvss7C0rr87+wNeTuT1/Q6aHYiGp1375jyVeXINpSmc0QnhWYMtYLgJisX+WCNEwP7YA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055496; c=relaxed/simple; bh=Hp5Kotv+V9yNIc4Tg2u+vJrrmMQdftSMs1SkQH7KC+k=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=WBVg/vprAE12NBAMLPH4AzWQyE2FnMxlN+mXvbYxd4KNaoR28fSmdy2YAbCm7AWvJVmvXaTahw4OqIueDQmrFTc8Z6O56390i00OCruTIZVHC9qOIIDNCAS53RDV2y6jKnIa2dcp+/ct3+p2v9RyCC/Tl5/Xk670n86GdEY7twA= 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=114.132.62.65 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: bizesmtpsz8t1712055405t6jdpo5 X-QQ-Originating-IP: zMSS9njKLfe5qpNl4MMAMhdArcJiYg0YoFBp8ktzVXQ= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Apr 2024 18:56:43 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: /gpUuYPpeIUOZ5s4aenzg3ecAzQ5K7SRWRK0Che4X0DDJnKnqcBFQ3cHWYAn9 cC/dPwRl0hcLzexcfoeO00x98gWN2YFe9xxEMIqqAwMtfS8gs12iNpMKdpHocr0FdLJwbcq +emWo5zvWekdtysQtOjjfOBqCVqCfJEKNxB7kSUUL5lvNVHQDOk5JBAOiw7Iu26y6O0B4Gb 9DqRc22fi4nNYUaDy7fftLuAwpVhNm/7Hl5Kc7rzSsPwn/riyxIOjFFO+hPOlPUqtHgqkGy cfrEyy2vTIS6l3JFKTwalV/DRu7+29DUKticbHws+GMLWcAshAdfwnhqvt86apeFvFyTLCU UCdFTaAMhQQNh9KermXJV28Vn3+Y7NnwJK3FE37g9nkVKf413DQMY49v7TfCA57vzfc6hWk VLW+wSF7XBU0RP/V2c0OmQ== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 5033886388015913016 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com 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 1/9] perf/alibaba_uncore_drw: Avoid explicit cpumask var allocation from stack Date: Tue, 2 Apr 2024 18:56:02 +0800 Message-Id: <20240402105610.1695644-2-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> References: <20240402105610.1695644-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. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li --- drivers/perf/alibaba_uncore_drw_pmu.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_u= ncore_drw_pmu.c index a9277dcf90ce..251f0a2dee84 100644 --- a/drivers/perf/alibaba_uncore_drw_pmu.c +++ b/drivers/perf/alibaba_uncore_drw_pmu.c @@ -743,25 +743,28 @@ static void ali_drw_pmu_remove(struct platform_device= *pdev) =20 static int ali_drw_pmu_offline_cpu(unsigned int cpu, struct hlist_node *no= de) { + cpumask_var_t node_online_cpus; 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, + if (!alloc_cpumask_var(&node_online_cpus, GFP_KERNEL)) + return 0; + + 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); + target =3D cpumask_any_but(node_online_cpus, cpu); else target =3D cpumask_any_but(cpu_online_mask, cpu); =20 if (target >=3D nr_cpu_ids) - return 0; + goto __free_cpumask; =20 /* We're only reading, but this isn't the place to be involving RCU */ mutex_lock(&ali_drw_pmu_irqs_lock); @@ -772,6 +775,8 @@ static int ali_drw_pmu_offline_cpu(unsigned int cpu, st= ruct hlist_node *node) WARN_ON(irq_set_affinity_hint(irq->irq_num, cpumask_of(target))); irq->cpu =3D target; =20 +__free_cpumask: + free_cpumask_var(node_online_cpus); return 0; } =20 --=20 2.27.0 From nobody Mon Feb 9 12:10:18 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 7EC497FBA6; Tue, 2 Apr 2024 10:57:57 +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=1712055481; cv=none; b=oOpgKyyi+7rQKmlZvf6XprodE01Hp2iBjm1vtAuOPOzI23F47Hplme4BuZYfvXJ5/zwhF+ue6RkOB5xO1vVETd4yWSqFmM1QiQr41fxZ3Cprwm599UbahPo6+7A2epeQIjPc7BqLOYNjuxjdL4scEUXgWFDzRxThcnWKHRB05pI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055481; c=relaxed/simple; bh=ZvjQTwcwJWrNuKxZ/U40Rg12tZQV5ecf7TdNFA4g0vo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=VljmaX7HoA0tEio3HGrn+HAK95Y+hY7KX36PynaYIXweV1ATtcVUR0KG+OICLwglH90JnLLtN4i1MTV7MpfIi9JQhXsRbwAApJQ26YwNT4eECwHiFKSwUQZgLla1R3Oy6FdWdvFYn+VQrqlYQGdd4c0xNtuQ+sduueqgjhUbBGc= 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: bizesmtpsz11t1712055412t3i2gh X-QQ-Originating-IP: F6TQ7P//4zKCDA4lZjfDOIcvWwLHa3rkwI4TauOF850= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Apr 2024 18:56:50 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: RrZlkntZBfnEBj5q3ATNBISnIDtwBbucJTGdzlgBBvrPwGxeSdaQrY2O7BNVi YN80SJcxNGBKWF0mruul/SsnAWrUS8ddgudFE1oKLS+jEevXvqDVNOKV7qFTXJ2rWhaiVwC wf53ZcO6SmAMsC3C1CJHDBF0dfZYwzSqn0K+iSYk5demHoOL9cBAnCJAZLi6wUcHGD/LLkb nVxeOLJ5wurYne7LYr/EDn7GE3nhxzVQNsZwtVJ0OsawWR+2wb6uTrsCVaOXr0rW+h88K9e 9WMOEptV2D/kJIUNt9z/2S5zmeqg9SEFNX4sRK/OfM1KWB9BocIU/Yyhz/wDFrUP6WiT3gP mXvRveYfpPSpxV/c+Z54oWRjyV5azHp3mf2Md5hIZtywx43saDBp89NTzKklvOo8k71L/49 1Vp4X/aU9ie3lhYq4qg9zQ== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 8890398727476667611 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com 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 2/9] perf/arm-cmn: Avoid explicit cpumask var allocation from stack Date: Tue, 2 Apr 2024 18:56:03 +0800 Message-Id: <20240402105610.1695644-3-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> References: <20240402105610.1695644-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. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li --- drivers/perf/arm-cmn.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c index 7ef9c7e4836b..7278fd72d3da 100644 --- a/drivers/perf/arm-cmn.c +++ b/drivers/perf/arm-cmn.c @@ -1949,21 +1949,26 @@ static int arm_cmn_pmu_offline_cpu(unsigned int cpu= , struct hlist_node *cpuhp_no { struct arm_cmn *cmn; unsigned int target; + cpumask_var_t mask; 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 + if (!alloc_cpumask_var(&mask, GFP_KERNEL)) + return 0; + 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); + 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_but(cpu_online_mask, cpu); if (target < nr_cpu_ids) arm_cmn_migrate(cmn, target); + + free_cpumask_var(mask); return 0; } =20 --=20 2.27.0 From nobody Mon Feb 9 12:10:18 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 77CBB664C6; Tue, 2 Apr 2024 10:58:05 +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=1712055489; cv=none; b=FHai8MOysveU+udNGvNy5J50MZf8x/4UJ1zYvoXzH30DTMgfHcbvm7wP0WCsOeP0sjYZNgAgVDe5SYHVm0chuse+5K0QOkif1ooWbGLFBT5bZDA75maQbjIkeAQ5Zcqf0/1pE5vSB6iB68fKJr7U6yRtBUGAw3jve4r8SX+6+C0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055489; c=relaxed/simple; bh=ogaNYTk5qfBchXVMhHi6q9EXDm5FtzGo5QVXZl2LRJs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=GNMkU0cLbGFGmEOzcw6bEf/8J/P++/Rsl53wmqKNNl0f7K9sjaFJ4zFdS6GeG31PfqQ3W305I5uNTCR+UFo/Hkm7Urg7C7/KFozqD1KFafz88sLGK3Qr6yQBNA6Q0j4qgglfhC7mklw7/M3DDrv5uz3kMeCndMo5LiP1hxY8nlg= 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: bizesmtp82t1712055417txrsjps3 X-QQ-Originating-IP: Zhhf+oUY7YGq4uJEDWQ5xEym8nwZtAJnOprlRBQnsy0= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Apr 2024 18:56:56 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: +ynUkgUhZJmh3bbpLZOdWsh1CuXcwJwfQmOYzh1es10m+h9VDxJ9F7Ia34mv/ nL8o8GlT62IzqZsPbFmA9QTSXK0zi31huiF9hyD/60DsLQb9NprTXGqon/YX9c14WR6LtqO Z/4d67SIP3vjyRbxhj8sR5zqCLemk+AIx7ozWCuNf3f9XwDNvC9mJYgvlndMT/+IIKvxNYF l8IZtDjohfhN8ZtW4tbL+rsoA8JqOAHPtPZyvmt0w0dbykyjy0s3TlkFHtbhaSjxoD9LRyR GKAkLJTSZ1OjxP9jWS0SVgNV1kme4FtDS3QRSLgxwQkBAQ8XCZ6DkoofJLwRgKjzyCRRvXY AdsCz/ZZwfjCtB/lUNnix1CXy3J27RwvMYHgFa0eZez8/WwJMVSpcXhf/Mb/Dcv9dovGqv4 caksZ5TvYjcs8jz7BpOGqA== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 711303368774048342 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com 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 3/9] perf/arm_cspmu: Avoid explicit cpumask var allocation from stack Date: Tue, 2 Apr 2024 18:56:04 +0800 Message-Id: <20240402105610.1695644-4-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> References: <20240402105610.1695644-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. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li --- drivers/perf/arm_cspmu/arm_cspmu.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/ar= m_cspmu.c index b9a252272f1e..8fa7c26aec28 100644 --- a/drivers/perf/arm_cspmu/arm_cspmu.c +++ b/drivers/perf/arm_cspmu/arm_cspmu.c @@ -1322,8 +1322,8 @@ 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) { + cpumask_var_t online_supported; int dst; - struct cpumask online_supported; =20 struct arm_cspmu *cspmu =3D hlist_entry_safe(node, struct arm_cspmu, cpuhp_node); @@ -1332,17 +1332,22 @@ static int arm_cspmu_cpu_teardown(unsigned int cpu,= struct hlist_node *node) if (!cpumask_test_and_clear_cpu(cpu, &cspmu->active_cpu)) return 0; =20 + if (!alloc_cpumask_var(&online_supported, GFP_KERNEL)) + return 0; + /* Choose a new CPU to migrate ownership of the PMU to */ - cpumask_and(&online_supported, &cspmu->associated_cpus, + cpumask_and(online_supported, &cspmu->associated_cpus, cpu_online_mask); - dst =3D cpumask_any_but(&online_supported, cpu); + dst =3D cpumask_any_but(online_supported, cpu); if (dst >=3D nr_cpu_ids) - return 0; + goto __free_cpumask; =20 /* Use this CPU for event counting */ perf_pmu_migrate_context(&cspmu->pmu, cpu, dst); arm_cspmu_set_active_cpu(dst, cspmu); =20 +__free_cpumask: + free_cpumask_var(online_supported); return 0; } =20 --=20 2.27.0 From nobody Mon Feb 9 12:10:18 2026 Received: from smtpbg153.qq.com (smtpbg153.qq.com [13.245.218.24]) (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 CD62A7FBA6; Tue, 2 Apr 2024 10:58:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.245.218.24 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055489; cv=none; b=gzKMaAw0QJd3lGH2LyboCN5amErxMEgCnU1rbMK3avYBpJD8S6udpdoRW2lEYOe4ZIQkoHfiifJ7HAtTmpOaMuYpWDlp1xzvVWko953/k44nTMNHjlt2dwqU1oqv+6pRgT6d9pPACnWw4KmY+zGsyqgi36/jiYAvrEYzObY3AIs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055489; c=relaxed/simple; bh=kBhgbN7veyPdJiucyzUm36iOG/7FCi2+n/Y5GolQDQY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Dk+Z19Ey0hETxsgeBESk//ZODA2S9O9C4QezuqRMMDf8/1YNZOWpWifvrXVEQI7MzHLqpWtJisOhNddCt1vhsQlbFW1TdxvZpOZZZZPh/fu+G29/nYnybJVTWb0td4lC7yb9V6xYV55x3uA8XXE7G5+y+7dBnZZUJgmtdl+oSYE= 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=13.245.218.24 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: bizesmtpsz6t1712055425t71idd1 X-QQ-Originating-IP: Un3ri6CHwwLui5oq45tA1OXYdCgmI9pohTO0oH1tBU0= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Apr 2024 18:57:04 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: RrZlkntZBfktBWsBF1E+TH5J6loXlgQ3eAU19WtoMF7qdeTVjXhPDBscmPite 2ovkkkqxI68M8HuFvipOvq8mq8IkFWrgg2ZajQUXeWRV5BA082MjJ5B+wQph7d+l9ItO8fj w/NCUcTAB6KgKgiJPO6LHkOzxog1FYAU128tjeKLiTgx0siyjehIhTkYX2Pm7Do1ivTfOVK DULIAgFBMAhH+hs8n4SqOqt9Rdh3SglT/1fTStlTmizTpxY2HnRf5J3Fivl2pSJtW7rF6PZ +GA+jzuMwnhLZJE9FEZe9nPipczqaLWRJHm8HH7yCT7b3QL7HMrwY1y3NJQOmgLUkIUqXTz EZ6PJaWFU8Snde9TL/2V8e0Tunk9dWY+nmtkc+LnLoTrcbIeYWWBqA4X96M+eXHwElKRTs7 x+JeeYCYIy95lDu7H5qvLw== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 6688925915623200332 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com 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 4/9] perf/arm_dsu: Avoid explicit cpumask var allocation from stack Date: Tue, 2 Apr 2024 18:56:05 +0800 Message-Id: <20240402105610.1695644-5-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> References: <20240402105610.1695644-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. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li --- drivers/perf/arm_dsu_pmu.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c index bae3ca37f846..87efdca05807 100644 --- a/drivers/perf/arm_dsu_pmu.c +++ b/drivers/perf/arm_dsu_pmu.c @@ -230,13 +230,21 @@ static const struct attribute_group *dsu_pmu_attr_gro= ups[] =3D { NULL, }; =20 -static int dsu_pmu_get_online_cpu_any_but(struct dsu_pmu *dsu_pmu, int cpu) +static unsigned int dsu_pmu_get_online_cpu_any_but(struct dsu_pmu *dsu_pmu= , int cpu) { - struct cpumask online_supported; + cpumask_var_t online_supported; + unsigned int ret; =20 - cpumask_and(&online_supported, - &dsu_pmu->associated_cpus, cpu_online_mask); - return cpumask_any_but(&online_supported, cpu); + if (!alloc_cpumask_var(&online_supported, GFP_KERNEL)) + return -ENOMEM; + + cpumask_and(online_supported, + &dsu_pmu->associated_cpus, cpu_online_mask); + ret =3D cpumask_any_but(&online_supported, cpu); + + free_cpumask_var(online_supported); + + return ret; } =20 static inline bool dsu_pmu_counter_valid(struct dsu_pmu *dsu_pmu, u32 idx) --=20 2.27.0 From nobody Mon Feb 9 12:10:18 2026 Received: from smtpbgeu2.qq.com (smtpbgeu2.qq.com [18.194.254.142]) (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 3F6F580BEE; Tue, 2 Apr 2024 10:58:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.194.254.142 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055486; cv=none; b=GblwOrhjw46lmpMwQjhDaSbUJ2j5ZudxMwA1LuJ2Ac4xY5WplPM+RNVPMJxi/+4j+EZzBVs5GYWjoUPPGCFIOhqmoTES+RVaYYJ5kBUAUEu6LD9NubOisIlwPWPgf6CzkekQ1IDxP2WqVaj9r17HFKQ5s75JnsJtkGF44cMPRA4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055486; c=relaxed/simple; bh=UD78b+Ao8lKwjj50NaM+HsEbsQALsMtRe09N+rD98HI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=qsu1xdcYNdtH78rvyJVQ+eE/1Kkf3N8u/uObu5xe6hWeVDv+XvNJsYzjKNGqytGBio4CPmtMebhZA4nry2zJTkj8yLr9WeP3LNjZax0L2XtrctVtzwpsWtx+X7D9v7JXvLVwMUP9GkorUFsLEd1gY4g54088gUle7aBwjMfpP+I= 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.194.254.142 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: bizesmtpsz10t1712055431tb6jud X-QQ-Originating-IP: f5R2VecJRELIO4EhbfBbAraDQpJloHN0LErZyEBfGhk= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Apr 2024 18:57:10 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: /gpUuYPpeIVF+4ZT8cHhA8f1Nym8iAKHB9yJxhFcqQIPnmtaClBuJ5UBbVQNM IEJIVlWFCEiAVpwNgfL3+wEC5zAc/v9VNgPtpLb2Nu3+hz6dKboZRGdqZdHMQ+0N03cwH1U zVW6Lnh9JP2B21xzyMzX4/G9WzXGa52g1YHpSnC0Isz9wvC5dj9j2bOfmvkLAQf5FlEqiES 3g3ZAYRiaoNPZtKNGHMAJUclEz/FQpDvQ149pbnEMoJXyK6y3OvsZgNwjprBKrmuQko0DPU LvKZeMuT9YpXKTLfbsfnewbG78wA8D7cvlmuhEOFjjbMQ1IgdJQe1MIXr+dJhuPRp9ram+i Ywxf5T8dqPqMU22rXG10pxPgy2AOnT62LcI09jlb2GiAeHzl5WAN8xrhXa5vwRYJSp2ybSK Mn62VFjduUiRVx/st/ykZg== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 7950645969911555121 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com 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 5/9] perf/dwc_pcie: Avoid explicit cpumask var allocation from stack Date: Tue, 2 Apr 2024 18:56:06 +0800 Message-Id: <20240402105610.1695644-6-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> References: <20240402105610.1695644-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. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li --- drivers/perf/dwc_pcie_pmu.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/perf/dwc_pcie_pmu.c b/drivers/perf/dwc_pcie_pmu.c index 957058ad0099..97037b6aaa97 100644 --- a/drivers/perf/dwc_pcie_pmu.c +++ b/drivers/perf/dwc_pcie_pmu.c @@ -690,33 +690,38 @@ static int dwc_pcie_pmu_offline_cpu(unsigned int cpu,= struct hlist_node *cpuhp_n { struct dwc_pcie_pmu *pcie_pmu; struct pci_dev *pdev; - int node; - cpumask_t mask; unsigned int target; + cpumask_var_t mask; + 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 */ if (cpu !=3D pcie_pmu->on_cpu) return 0; =20 + if (!alloc_cpumask_var(&mask, GFP_KERNEL)) + return 0; + 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); + 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_but(cpu_online_mask, cpu); =20 if (target >=3D nr_cpu_ids) { pci_err(pdev, "There is no CPU to set\n"); - return 0; + goto __free_cpumask; } =20 /* This PMU does NOT support interrupt, just migrate context. */ perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target); pcie_pmu->on_cpu =3D target; =20 +__free_cpumask: + free_cpumask_var(mask); return 0; } =20 --=20 2.27.0 From nobody Mon Feb 9 12:10:18 2026 Received: from smtpbgau1.qq.com (smtpbgau1.qq.com [54.206.16.166]) (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 77881679FE; Tue, 2 Apr 2024 10:58:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.206.16.166 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055490; cv=none; b=VdPceFnslBt3fCy2+cRUF/TE4nfwWfhpL6GPQXXBUS2ngDnPCss/lq8qgwsp2a0DGB8jan5jWQqYc6adXGbCvmdSefO/Q0SPLFnaTjDko3Sec85MAG7OkPuje7zEDF0Z7EFQ97Dk4+vvfyWmosFbZRn8m20xCOl3nNlgLRCFscw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055490; c=relaxed/simple; bh=9SMagf4ekuVVWbkzGuSoqtWRQyTjn1UdNYmj02yzq0w=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=WgaYjad7/RmK7dNIWnAScxtF6LDieXC1QwBS4wUc6lW5TPHgz+CCtBeQbQ2iXh+QFqqVbrHL+zXRIS8LrNJ68UVY7kH5BQrYzmC5B/lxfYEVKnBYTisoXzfPr5yh9eV4ujBZkwbY5mG2nuz6Cy/Pokk3Ld8p3wBSYzQSWvG69rs= 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.16.166 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: bizesmtpsz4t1712055438t100kkc X-QQ-Originating-IP: a5WUCvce6dh0AODow/y0bafKjSIzl0D3SGfsgjaK8rw= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Apr 2024 18:57:16 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: xQoAiglG4R7OzHcG3WRIL6bRJptP9X4BvxCofIJYBT8FiM2BTyzff5hJU5bed eaCrWLkzdr6ZQcZ1J/m11oqaAXCxzlbLodPL6HusvHXm5ue5MeWF650CVMB51fG99wJmU7x ++vWK1WJA9kR4gKQEWX/PHBD7CI+c1TdERTNDkWcLU04xi8ly6zMRoeR7ihTTFEcBvBkE/d sIUEm5kGHeYuOX3ouLbZgHQpFexDECSq+XBUf72oqJgUDw2SXKRqy0gi3Grq1jXLVMHR2G+ wro2e2kIpVwBmFoDITBcEbJZkNjV4FSXWTgsZrfJsyYMIkDg5lvXiCzds38v//Thm1QYP5U zG3+Sxn9/bpYWgorM2qhT+jy7/1wXu3k3HjgCYiORuXTXm21v3KDQdhAHKMmm/EGeDWQ/ra aDVzxfIpZeKxvlmrSu08PQ== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 16629059824936598308 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com 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 6/9] perf/hisi_pcie: Avoid explicit cpumask var allocation from stack Date: Tue, 2 Apr 2024 18:56:07 +0800 Message-Id: <20240402105610.1695644-7-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> References: <20240402105610.1695644-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. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li --- drivers/perf/hisilicon/hisi_pcie_pmu.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/perf/hisilicon/hisi_pcie_pmu.c b/drivers/perf/hisilico= n/hisi_pcie_pmu.c index 5d1f0e9fdb08..0183640db2de 100644 --- a/drivers/perf/hisilicon/hisi_pcie_pmu.c +++ b/drivers/perf/hisilicon/hisi_pcie_pmu.c @@ -673,26 +673,29 @@ 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; + cpumask_var_t mask; int numa_node; =20 /* Nothing to do if this CPU doesn't own the PMU */ if (pcie_pmu->on_cpu !=3D cpu) return 0; =20 + if (!alloc_cpumask_var(&mask, GFP_KERNEL)) + return 0; + pcie_pmu->on_cpu =3D -1; =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); + 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_but(cpu_online_mask, cpu); =20 if (target >=3D nr_cpu_ids) { pci_err(pcie_pmu->pdev, "There is no CPU to set\n"); - return 0; + goto __free_cpumask; } =20 perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target); @@ -700,6 +703,8 @@ static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, = struct hlist_node *node) pcie_pmu->on_cpu =3D target; WARN_ON(irq_set_affinity(pcie_pmu->irq, cpumask_of(target))); =20 +__free_cpumask: + free_cpumask_var(mask); return 0; } =20 --=20 2.27.0 From nobody Mon Feb 9 12:10:18 2026 Received: from bg1.exmail.qq.com (bg1.exmail.qq.com [114.132.77.159]) (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 AC268604C8; Tue, 2 Apr 2024 10:58:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=114.132.77.159 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055523; cv=none; b=TBvxU81eDVdZIXryMNAHjDggpdaMGcQ6BKglnDK6meunoy2oCC2Pt0T6IxW37XuR6ysktmw96naV9SnNiQZr8wpUVTAQTbWetyo6x3026Or8R9eBlrcFmYiHoj8GYCmjISU/xPP+QBZ8S+MxPPImFl8xcOjcBGInFJeIudWk1Dc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055523; c=relaxed/simple; bh=EpGppEMctUZVg/y6NfsAZO5VgivZhhbrlYGn+JnuFRE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=kQyiMngLJpRzusDY3dUCQerRdsDG5E1FwIK3IFmsPQyQJDJLwLVOfYQr6QYUEZ5xvyHqfvitkR3Z9+JUGWuNy0SAdVVF+oGQTn2tn7ZepQSOzenA6hBJ3wS2n5lQlJ3lu2VYSdPipPTUfOd1oXCcwnTDogaq5kM62sHLOcgOZqM= 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=114.132.77.159 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: bizesmtpsz11t1712055445thvlyu X-QQ-Originating-IP: Gi/zIc7rVg0nbwrff8zyxNmy8QhoIujNcA126m1YLzA= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Apr 2024 18:57:24 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: oH0qrucfWSzFqe9iiuJWrQbXT3+hF7FViMjye7PQ7tMx+WAd07wFqawEYOHIi JvhzhYFM7DxB7np8RUejiLG05a1eqBYpBHd2E2yQsRV0tKruLW9G+7AR74nQNIbc96P/YN9 F9DqLnSpgWlaOLEVgJUPjMb/W5IRv3rYY168IsP3Xck+kvAn9NiSO4Z8XiGMKnX8EeCxu41 +Zdbyx8c2vTJpJGgXaVSTjwmb5pM1S+CtX1+7WvKF4EjkZCZVdRbOf37dVFQzW1/9nssHyr UgSJQv9QtSAdHJXwD8VDFbDEgNTOTjNb5dFvAfVa6NQuTfo9364Kl7/V2j/rNOZGAALKA2D QpRhoIp/1NPwQd3JFXQQLFMY92yRULneQGggzXRo6c6Ufk7pDWaa/6xAELE8iDiUo+Vnb2g rs8K4IhG/a0l6aSuJSkLWg== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 17509807497334739871 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com 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 7/9] perf/hisi_uncore: Avoid explicit cpumask var allocation from stack Date: Tue, 2 Apr 2024 18:56:08 +0800 Message-Id: <20240402105610.1695644-8-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> References: <20240402105610.1695644-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. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li --- drivers/perf/hisilicon/hisi_uncore_pmu.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c b/drivers/perf/hisili= con/hisi_uncore_pmu.c index 04031450d5fe..06891d23b21c 100644 --- a/drivers/perf/hisilicon/hisi_uncore_pmu.c +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c @@ -504,7 +504,7 @@ 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; + cpumask_var_t pmu_online_cpus; unsigned int target; =20 if (!cpumask_test_and_clear_cpu(cpu, &hisi_pmu->associated_cpus)) @@ -514,21 +514,26 @@ int hisi_uncore_pmu_offline_cpu(unsigned int cpu, str= uct hlist_node *node) if (hisi_pmu->on_cpu !=3D cpu) return 0; =20 + if (!alloc_cpumask_var(&pmu_online_cpus, GFP_KERNEL)) + return 0; + /* Give up ownership of the PMU */ 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, + 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_but(pmu_online_cpus, cpu); if (target >=3D nr_cpu_ids) - return 0; + goto __free_cpumask; =20 perf_pmu_migrate_context(&hisi_pmu->pmu, cpu, target); /* Use this CPU for event counting */ hisi_pmu->on_cpu =3D target; WARN_ON(irq_set_affinity(hisi_pmu->irq, cpumask_of(target))); =20 +__free_cpumask: + free_cpumask_var(pmu_online_cpus); return 0; } EXPORT_SYMBOL_GPL(hisi_uncore_pmu_offline_cpu); --=20 2.27.0 From nobody Mon Feb 9 12:10:18 2026 Received: from smtpbg156.qq.com (smtpbg156.qq.com [15.184.82.18]) (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 9FD61605C6; Tue, 2 Apr 2024 10:58:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=15.184.82.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055510; cv=none; b=Xqv1vaVGjEITxf0MXM1WlHV+ZkBY3OLrpXIS+chVKHVnC9jqDrfdmyUJ8CFrZGSnGw8B5KcehCjLtM49jWUpP+o/PJ7Bh9Mm3eh2Q0dMzASoxwIeVGQKG5PVU76zuLKXXHhRf3csAlI8sjUvcWPET+Dlh1VGZDmCoGML5Xfg1Tg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055510; c=relaxed/simple; bh=RnffjsKX2UYc8upK6sWTNPvoU/wb++tR7MPvg11VYzU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=XBkFf6ClP70dOI1k4TjuVLPOSr0+uxmGrKagH9AZu7ClW4qoFrznYveyyU8RhF8gJFLAaLIFgXZLEqjT55D0mNRXTL9J8UhKi/I1ScHoGL/BvJEJ7R1qHHDZBZHsDoufp5WqEYCNhXiBuercNvakDSFCeWWjuWgWwD4+lyLXDhk= 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.82.18 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: bizesmtp79t1712055451tfob8lde X-QQ-Originating-IP: PvsZUuatj8QZ641yXn+lcd5OMQTi7GdjZdQznKAkR/c= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Apr 2024 18:57:30 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: 3M0okmaRx3jH2qX8AogQHU2fcWNrGo2m8LilTigAJGetQhSvXHKYfErP0NM75 LrLgEVYP1YRb8qe3MRdxEekWoo5hH08O0sfTXLO/ew6InuqS9bX8bCQzX9wpBoCEnYIftWx 0Iiy8irGQWVfNVew8n5ovD3FhludIYtnYSe8TB7KcbcuECYTOVGti7aIQ6SBdScG7kPu24i OSuEHuOzvNe2m3J0XBsN5R2ab9casuA2B8Mbb/MJudJNNqMJTBbSebRwrbTKt+d0veZqblc mTclwuGYYfoZbHa+LltKPPFuNEaRFC7dns6y+ICp8/kR5nGWn54YsFNkUFUoj/hzJIfGY3O G94XtmzoQFTPOJg6AMG9Pw4J8XCAVF1ntPTGe8FI0ZWQm5W0sMj+4gLDbm1WT7EXj9Uwt+Z oTMaqai9+7g= X-QQ-GoodBg: 2 X-BIZMAIL-ID: 1383880197546244670 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com 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 8/9] perf/qcom_l2: Avoid explicit cpumask var allocation from stack Date: Tue, 2 Apr 2024 18:56:09 +0800 Message-Id: <20240402105610.1695644-9-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> References: <20240402105610.1695644-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. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li --- drivers/perf/qcom_l2_pmu.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/perf/qcom_l2_pmu.c b/drivers/perf/qcom_l2_pmu.c index 148df5ae8ef8..8fe0c7557521 100644 --- a/drivers/perf/qcom_l2_pmu.c +++ b/drivers/perf/qcom_l2_pmu.c @@ -801,9 +801,9 @@ 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; + cpumask_var_t cluster_online_cpus; 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); @@ -815,17 +815,20 @@ static int l2cache_pmu_offline_cpu(unsigned int cpu, = struct hlist_node *node) if (cluster->on_cpu !=3D cpu) return 0; =20 + if (!alloc_cpumask_var(&cluster_online_cpus, GFP_KERNEL)) + return 0; + /* Give up ownership of cluster */ cpumask_clear_cpu(cpu, &l2cache_pmu->cpumask); cluster->on_cpu =3D -1; =20 /* Any other CPU for this cluster which is still online */ - cpumask_and(&cluster_online_cpus, &cluster->cluster_cpus, + cpumask_and(cluster_online_cpus, &cluster->cluster_cpus, cpu_online_mask); - target =3D cpumask_any_but(&cluster_online_cpus, cpu); + target =3D cpumask_any_but(cluster_online_cpus, cpu); if (target >=3D nr_cpu_ids) { disable_irq(cluster->irq); - return 0; + goto __free_cpumask; } =20 perf_pmu_migrate_context(&l2cache_pmu->pmu, cpu, target); @@ -833,6 +836,8 @@ static int l2cache_pmu_offline_cpu(unsigned int cpu, st= ruct hlist_node *node) cpumask_set_cpu(target, &l2cache_pmu->cpumask); WARN_ON(irq_set_affinity(cluster->irq, cpumask_of(target))); =20 +__free_cpumask: + free_cpumask_var(cluster_online_cpus); return 0; } =20 --=20 2.27.0 From nobody Mon Feb 9 12:10:18 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 9AA8F612E1; Tue, 2 Apr 2024 10:58:50 +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=1712055533; cv=none; b=OKIGEzM+GNlF0ajmfXapWjvtMiwfanCsEDeD628r52OWbO4bm6djhiN8LfZVv95TEiRs6GhrPMnaNBb/IyXpjNB15WElBzQ1bQXZPblpoYDQlicFfjguSw9DNDkmoAZBCo9OanmeNCq5A4LeZ689E0jCqE+JorDHGxorkUn55E0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712055533; c=relaxed/simple; bh=ShsobMlYFwfwHqa29pcXbmIcP14z7/wd2QAvOg8eylM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=DtXC6OgNg7exTU0TW2cdygT3xsnrW44GUSSKtXdw0YoLz7XMx61VQBN+fA1Jhu5ze3KTIyFxEkpa6gxowV4lGslnjbOwub/GcFdMcAoKMITIb6YrIcY+8Oc1gDvmVRWZv1xRfSuXC22ScODS2fWpKcng0NABWpKG7saCz/2irpw= 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: bizesmtpsz7t1712055482t8hhr29 X-QQ-Originating-IP: AIcr+JMMiHNAe9ivs3l6hnjCuJ93m5xNH9hw9O48loQ= Received: from localhost ( [112.0.147.175]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 02 Apr 2024 18:58:00 +0800 (CST) X-QQ-SSF: 01400000000000704000000A0000000 X-QQ-FEAT: 3M0okmaRx3jDSki7LRBGbMl6eVjhJrP7hy+2d57Zwz9+hkzPLSG00e+1ByNRJ xCUqV/VaOH9XPhyMNY6fXwGTZkOUIOF7FwM9vxUNJTyzeHF+BJ7JjtJ443q4nZzWvAFRe89 5q6ewnYehc0YZfYalerNRGY19Re1KFcJ7z2BrSuBDEWvqVKiYyr9CNnhDeTfnKq142ZVAHv 4C9u0f5MohXsc3rTyWoYZlXRKC7yJWlyqUJgSxEN5ardzQSwc7WjJ3VtJhXemJzTDWqbQRW 6yCjzYBZrAzM1dAY6tOfZLAeBxOAc6O+3d4Y6rB6KRcldI1/Kr9C4a6CtRV9ABWwdGc57D5 Wihf/pxeEVr5f4qy20Gqh7kF2Ekt1q9Pkg3Ke/b+VumTe+eyU93WGAXd8BBtzTbChLjA4b9 +bVJTMCVliEvQxnRyGxyWA== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 17135480200508921622 From: Dawei Li To: will@kernel.org, mark.rutland@arm.com 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 9/9] perf/thunder_x2: Avoid explicit cpumask var allocation from stack Date: Tue, 2 Apr 2024 18:56:10 +0800 Message-Id: <20240402105610.1695644-10-dawei.li@shingroup.cn> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn> References: <20240402105610.1695644-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. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li --- drivers/perf/thunderx2_pmu.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c index e16d10c763de..8a02a4533b32 100644 --- a/drivers/perf/thunderx2_pmu.c +++ b/drivers/perf/thunderx2_pmu.c @@ -932,9 +932,9 @@ 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; + cpumask_var_t cpu_online_mask_temp; struct tx2_uncore_pmu *tx2_pmu; - struct cpumask cpu_online_mask_temp; + int new_cpu; =20 tx2_pmu =3D hlist_entry_safe(hpnode, struct tx2_uncore_pmu, hpnode); @@ -945,17 +945,21 @@ static int tx2_uncore_pmu_offline_cpu(unsigned int cp= u, 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); + if (!alloc_cpumask_var(&cpu_online_mask_temp, GFP_KERNEL)) + return 0; + + 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); =20 tx2_pmu->cpu =3D new_cpu; if (new_cpu >=3D nr_cpu_ids) - return 0; + goto __free_cpumask; perf_pmu_migrate_context(&tx2_pmu->pmu, cpu, new_cpu); =20 +__free_cpumask: + free_cpumask_var(cpu_online_mask_temp); return 0; } =20 --=20 2.27.0