[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200226095134.GM28029@codeaurora.org>
Date: Wed, 26 Feb 2020 15:21:34 +0530
From: Pavan Kondeti <pkondeti@...eaurora.org>
To: Ionela Voinescu <ionela.voinescu@....com>
Cc: catalin.marinas@....com, will@...nel.org, mark.rutland@....com,
maz@...nel.org, suzuki.poulose@....com, sudeep.holla@....com,
lukasz.luba@....com, valentin.schneider@....com,
dietmar.eggemann@....com, rjw@...ysocki.net, peterz@...radead.org,
mingo@...hat.com, vincent.guittot@...aro.org,
viresh.kumar@...aro.org, linux-arm-kernel@...ts.infradead.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org
Subject: Re: [PATCH v4 6/7] arm64: use activity monitors for frequency
invariance
On Mon, Feb 24, 2020 at 02:11:41PM +0000, Ionela Voinescu wrote:
[...]
> +static int __init init_amu_fie(void)
> +{
> + cpumask_var_t valid_cpus;
> + bool have_policy = false;
> + int cpu;
> +
> + if (!zalloc_cpumask_var(&valid_cpus, GFP_KERNEL) ||
> + !zalloc_cpumask_var(&amu_fie_cpus, GFP_KERNEL))
> + return -ENOMEM;
The patch looks good to me. one minor comment here. In an unlikely
scenario, valid_cpus which is a temporary mask can get allocated
but amu_fie_cpus may not. In that case, we have to free valid_cpus
here. I have seen some static code inspection tools catching these
type of errors. If you happen to rebase this series, fix this.
Thanks,
Pavan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Powered by blists - more mailing lists