From: Mark Rutland <mark.rutland@arm.com>
To: Dawei Li <dawei.li@shingroup.cn>
Cc: will@kernel.org, xueshuai@linux.alibaba.com,
renyu.zj@linux.alibaba.com, yangyicong@hisilicon.com,
jonathan.cameron@huawei.com, andersson@kernel.org,
konrad.dybcio@linaro.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 1/9] perf/alibaba_uncore_drw: Avoid explicit cpumask var allocation from stack
Date: Tue, 2 Apr 2024 12:06:52 +0100 [thread overview]
Message-ID: <ZgvmzKHD_wfdOLK2@FVFF77S0Q05N> (raw)
In-Reply-To: <20240402105610.1695644-2-dawei.li@shingroup.cn>
On Tue, Apr 02, 2024 at 06:56:02PM +0800, Dawei Li wrote:
> For CONFIG_CPUMASK_OFFSTACK=y 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 <dawei.li@shingroup.cn>
> ---
> 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_uncore_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)
>
> static int ali_drw_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> {
> + 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;
>
> irq = hlist_entry_safe(node, struct ali_drw_pmu_irq, node);
> if (cpu != irq->cpu)
> return 0;
>
> - ret = cpumask_and(&node_online_cpus,
> + if (!alloc_cpumask_var(&node_online_cpus, GFP_KERNEL))
> + return 0;
NAK. This error path leaves things in an incorrect state and this approach does
not make sense.
Please allocate the cpumasks when we allocate the PMU. Then we can reasonably
fail to probe the PMU if we don't have enough memory, and the masks will
definitely be accessible in gotplug paths.
The same comment applies to the whole series.
Mark.
> +
> + ret = cpumask_and(node_online_cpus,
> cpumask_of_node(cpu_to_node(cpu)), cpu_online_mask);
> if (ret)
> - target = cpumask_any_but(&node_online_cpus, cpu);
> + target = cpumask_any_but(node_online_cpus, cpu);
> else
> target = cpumask_any_but(cpu_online_mask, cpu);
>
> if (target >= nr_cpu_ids)
> - return 0;
> + goto __free_cpumask;
>
> /* 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, struct hlist_node *node)
> WARN_ON(irq_set_affinity_hint(irq->irq_num, cpumask_of(target)));
> irq->cpu = target;
>
> +__free_cpumask:
> + free_cpumask_var(node_online_cpus);
> return 0;
> }
>
> --
> 2.27.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-04-02 11:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 10:56 [PATCH 0/9] perf: Avoid explicit cpumask var allocation from stack Dawei Li
2024-04-02 10:56 ` [PATCH 1/9] perf/alibaba_uncore_drw: " Dawei Li
2024-04-02 11:06 ` Mark Rutland [this message]
2024-04-02 10:56 ` [PATCH 2/9] perf/arm-cmn: " Dawei Li
2024-04-05 14:30 ` Robin Murphy
2024-04-02 10:56 ` [PATCH 3/9] perf/arm_cspmu: " Dawei Li
2024-04-02 10:56 ` [PATCH 4/9] perf/arm_dsu: " Dawei Li
2024-04-02 23:58 ` kernel test robot
2024-04-03 1:43 ` kernel test robot
2024-04-02 10:56 ` [PATCH 5/9] perf/dwc_pcie: " Dawei Li
2024-04-02 10:56 ` [PATCH 6/9] perf/hisi_pcie: " Dawei Li
2024-04-02 10:56 ` [PATCH 7/9] perf/hisi_uncore: " Dawei Li
2024-04-02 10:56 ` [PATCH 8/9] perf/qcom_l2: " Dawei Li
2024-04-02 10:56 ` [PATCH 9/9] perf/thunder_x2: " Dawei Li
2024-04-02 11:12 ` [PATCH 0/9] perf: " Mark Rutland
2024-04-02 13:40 ` Dawei Li
2024-04-02 14:41 ` Mark Rutland
2024-04-03 10:41 ` Dawei Li
2024-04-03 11:10 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZgvmzKHD_wfdOLK2@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=andersson@kernel.org \
--cc=dawei.li@shingroup.cn \
--cc=jonathan.cameron@huawei.com \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=renyu.zj@linux.alibaba.com \
--cc=will@kernel.org \
--cc=xueshuai@linux.alibaba.com \
--cc=yangyicong@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).