| Message ID | 20191018000431.1675281-1-jhubbard@nvidia.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | cpufreq: powernv: fix stack bloat and NR_CPUS limitation | expand |
On 17-10-19, 17:04, 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=] How come we are catching this warning after 4 years ? > > This is due to putting 1024 bytes on the stack: > > unsigned int chip[256]; > > ...and while looking at this, it also has a bug: it fails with a stack > overrun, if CONFIG_NR_CPUS > 256. > > Fix both problems by dynamically allocating based on CONFIG_NR_CPUS. > > Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") > 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> > --- > > Hi, > > I have only compile-tested this, so I would appreciate if anyone > could do a basic runtime test on it. But (famous last words) it > seems simple enough that I'm confident it's correct. oh boy. :) > > thanks, > John Hubbard > NVIDIA > > drivers/cpufreq/powernv-cpufreq.c | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c > index 6061850e59c9..78e04402125f 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(CONFIG_NR_CPUS, sizeof(int), GFP_KERNEL); sizeof(*chip) > + if (!chips) (!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) > -- > 2.23.0
On 10/17/19 9:27 PM, Viresh Kumar wrote: > On 17-10-19, 17:04, 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=] > > How come we are catching this warning after 4 years ? > Newer compilers. And btw, I don't spend a lot of time in powerpc code, so I just recently ran this, and I guess everyone has been on less new compilers so far, it seems. I used a gcc 8.1 cross compiler in this case: $ $ /blue_exp/kernel/cross-compilers/powerpc64/gcc-8.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -v Using built-in specs. COLLECT_GCC=/blue_exp/kernel/cross-compilers/powerpc64/gcc-8.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc COLLECT_LTO_WRAPPER=/home/jhubbard/blue_exp/kernel/cross-compilers/powerpc64/gcc-8.1.0-nolibc/powerpc64-linux/bin/../libexec/gcc/powerpc64-linux/8.1.0/lto-wrapper Target: powerpc64-linux Configured with: /home/arnd/git/gcc/configure --target=powerpc64-linux --enable-targets=all --prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/powerpc64-linux --enable-languages=c --without-headers --disable-bootstrap --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --disable-libquadmath --disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release Thread model: single gcc version 8.1.0 (GCC) thanks, John Hubbard NVIDIA
On 17-10-19, 21:34, John Hubbard wrote: > On 10/17/19 9:27 PM, Viresh Kumar wrote: > > On 17-10-19, 17:04, 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=] > > > > How come we are catching this warning after 4 years ? > > > > Newer compilers. And btw, I don't spend a lot of time in powerpc > code, so I just recently ran this, and I guess everyone has been on less > new compilers so far, it seems. > > I used a gcc 8.1 cross compiler in this case: Hmm, okay. I hope you haven't missed my actual review comments on your patch, just wanted to make sure we don't end up waiting for each other indefinitely here :)
On 10/17/19 9:38 PM, Viresh Kumar wrote: > On 17-10-19, 21:34, John Hubbard wrote: >> On 10/17/19 9:27 PM, Viresh Kumar wrote: >>> On 17-10-19, 17:04, 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=] >>> >>> How come we are catching this warning after 4 years ? >>> >> >> Newer compilers. And btw, I don't spend a lot of time in powerpc >> code, so I just recently ran this, and I guess everyone has been on less >> new compilers so far, it seems. >> >> I used a gcc 8.1 cross compiler in this case: > > Hmm, okay. > > I hope you haven't missed my actual review comments on your patch, > just wanted to make sure we don't end up waiting for each other > indefinitely here :) > Ha, I did overlook those. It's late around here, I guess. :) I'll send a v2 with those changes. thanks, John Hubbard NVIDIA
On 17-10-19, 21:41, John Hubbard wrote: > On 10/17/19 9:38 PM, Viresh Kumar wrote: > > On 17-10-19, 21:34, John Hubbard wrote: > >> On 10/17/19 9:27 PM, Viresh Kumar wrote: > >>> On 17-10-19, 17:04, 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=] > >>> > >>> How come we are catching this warning after 4 years ? > >>> > >> > >> Newer compilers. And btw, I don't spend a lot of time in powerpc > >> code, so I just recently ran this, and I guess everyone has been on less > >> new compilers so far, it seems. > >> > >> I used a gcc 8.1 cross compiler in this case: > > > > Hmm, okay. > > > > I hope you haven't missed my actual review comments on your patch, > > just wanted to make sure we don't end up waiting for each other > > indefinitely here :) > > > > Ha, I did overlook those. It's late around here, I guess. :) Good that I reminded you then :)
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c index 6061850e59c9..78e04402125f 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(CONFIG_NR_CPUS, sizeof(int), GFP_KERNEL); + if (!chips) + 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 due to putting 1024 bytes on the stack: unsigned int chip[256]; ...and while looking at this, it also has a bug: it fails with a stack overrun, if CONFIG_NR_CPUS > 256. Fix both problems by dynamically allocating based on CONFIG_NR_CPUS. Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") 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> --- Hi, I have only compile-tested this, so I would appreciate if anyone could do a basic runtime test on it. But (famous last words) it seems simple enough that I'm confident it's correct. oh boy. :) thanks, John Hubbard NVIDIA drivers/cpufreq/powernv-cpufreq.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)