| Message ID | 20191031052159.4125031-1-jhubbard@nvidia.com (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Headers | show |
| Series | [v3] cpufreq: powernv: fix stack bloat and hard limit on num cpus | expand |
On Thu, 31 Oct 2019 at 10:52, John Hubbard <jhubbard@nvidia.com> wrote: > > The following build warning occurred on powerpc 64-bit builds: > > drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': > drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of > 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] > > This is with a cross-compiler based on gcc 8.1.0, which I got from: > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ > > The warning is due to putting 1024 bytes on the stack: > > unsigned int chip[256]; > > ...and it's also undesirable to have a hard limit on the number of > CPUs here. > > Fix both problems by dynamically allocating based on num_possible_cpus, > as recommended by Michael Ellerman. > > Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> > Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: Rafael J. Wysocki <rjw@rjwysocki.net> > Cc: linux-pm@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: John Hubbard <jhubbard@nvidia.com> > --- Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
On Thursday, October 31, 2019 6:21:59 AM CET John Hubbard wrote: > The following build warning occurred on powerpc 64-bit builds: > > drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': > drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of > 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] > > This is with a cross-compiler based on gcc 8.1.0, which I got from: > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ > > The warning is due to putting 1024 bytes on the stack: > > unsigned int chip[256]; > > ...and it's also undesirable to have a hard limit on the number of > CPUs here. > > Fix both problems by dynamically allocating based on num_possible_cpus, > as recommended by Michael Ellerman. > > Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> > Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: Rafael J. Wysocki <rjw@rjwysocki.net> > Cc: linux-pm@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: John Hubbard <jhubbard@nvidia.com> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > --- > > Changes since v2: applied fixes from Michael Ellerman's review: > > * Changed from CONFIG_NR_CPUS to num_possible_cpus() > > * Fixed up commit description: added a note about exactly which > compiler generates the warning. And softened up wording about > the limitation on number of CPUs. > > Changes since v1: includes Viresh's review commit fixes. Applying as 5.5 material, thanks!
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c index 6061850e59c9..56f4bc0d209e 100644 --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c @@ -1041,9 +1041,14 @@ static struct cpufreq_driver powernv_cpufreq_driver = { static int init_chip_info(void) { - unsigned int chip[256]; + unsigned int *chip; unsigned int cpu, i; unsigned int prev_chip_id = UINT_MAX; + int ret = 0; + + chip = kcalloc(num_possible_cpus(), sizeof(*chip), GFP_KERNEL); + if (!chip) + return -ENOMEM; for_each_possible_cpu(cpu) { unsigned int id = cpu_to_chip_id(cpu); @@ -1055,8 +1060,10 @@ static int init_chip_info(void) } chips = kcalloc(nr_chips, sizeof(struct chip), GFP_KERNEL); - if (!chips) - return -ENOMEM; + if (!chips) { + ret = -ENOMEM; + goto free_and_return; + } for (i = 0; i < nr_chips; i++) { chips[i].id = chip[i]; @@ -1066,7 +1073,9 @@ static int init_chip_info(void) per_cpu(chip_info, cpu) = &chips[i]; } - return 0; +free_and_return: + kfree(chip); + return ret; } static inline void clean_chip_info(void)
The following build warning occurred on powerpc 64-bit builds: drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] This is with a cross-compiler based on gcc 8.1.0, which I got from: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ The warning is due to putting 1024 bytes on the stack: unsigned int chip[256]; ...and it's also undesirable to have a hard limit on the number of CPUs here. Fix both problems by dynamically allocating based on num_possible_cpus, as recommended by Michael Ellerman. Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: linux-pm@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: John Hubbard <jhubbard@nvidia.com> --- Changes since v2: applied fixes from Michael Ellerman's review: * Changed from CONFIG_NR_CPUS to num_possible_cpus() * Fixed up commit description: added a note about exactly which compiler generates the warning. And softened up wording about the limitation on number of CPUs. Changes since v1: includes Viresh's review commit fixes. thanks, John Hubbard NVIDIA drivers/cpufreq/powernv-cpufreq.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)