Re: div_u64/do_div stack size usage, was Re: [v3] block: Removed a warning while compiling with a cross compiler for parisc

[Helge Deller]

On 7/7/21 10:39 PM, Arnd Bergmann wrote:
> On Wed, Jul 7, 2021 at 3:36 PM Helge Deller <deller@xxxxxx> wrote:
> > * Arnd Bergmann <arnd@xxxxxxxx>:
> > > My first thought was this was a result of -finline-functions getting
> > > enabled by default in gcc-10, but enabling it on gcc-9 did not
> > > help here. It's likely that the gcc behavior was fixed in the process
> > > of enabling the more aggressive inliner by default though.
> > >
> > > I also tried building genhd.o for every architecture that has
> > > gcc-9.4 support and did not find the problem anywhere except
> > > on parisc.
> > >
> > > Using CONFIG_CC_OPTIMIZE_FOR_SIZE did solve the
> > > problem for me (frame size down to 164 bytes), but I could not
> > > pinpoint a specific -f option that fixes it for -O2. Maybe we can
> > > simply change the defconfig here? 32-bit parisc systems are
> > > probably memory limited enough that building a -Os kernel
> > > is a good idea anyway. 64-bit parisc already builds with -Os
> > > but does not see the warning with -O2 either.
> >
> > I agree that the simplest solution is to increase the default value for
> > parisc here.
> > On parisc we have a 32k stack (either 1x32k or 2x16k when using IRQ
> > stacks). I increased the default value to 1280 in 2017, but as can be
> > seen here this isn't sufficient. Either way, we have an active runtime
> > check for stack overflows which has never triggered yet, so let's just
> > remove the compiler warning by increasing the value to 2048. Patch is
> > below.
> >
> > [PATCH] parisc: Increase gcc stack frame check to 2048 for 32- and 64-bit
> >
> > parisc uses much bigger frames than other architectures, so increase the
> > stack frame check value to 2048 to avoid compiler warnings.
>
> I think setting it to 2048 is rather excessive,

Since parisc needs roughly twice the frame (and stack) size as x86,
2048 seemed logical since that's the double of what's used on x86.
Of course we can reduce it, e.g. to 1536.

> and it would make you miss other real bugs. What I suggested was to
> change the defconfig to use CONFIG_CC_OPTIMIZE_FOR_SIZE instead.

But then you still will see those warnings in case you choose to not
optize for size.

> The reasoning for the 1280 byte limit on parisc is that it needs a few extra
> bytes for its larger stack frames, and 1024 for the other 32-bit architectures
> is only there because anything smaller warns for a handful of functions
> that are fine-tuned to need slightly less than that, when the call chain
> is predictable and using less would impact performance.
>
> I actually think we should reduce the warning limit for 64-bit architectures
> to 1280 bytes as well, but that triggers a couple of warnings that still
> need to be resolved first. In almost all cases, a kernel function needing
> more than 512 bytes is an indication of either a bug in the kernel, or
> (rarely) in the compiler.

or bad coding, e.g. huge local variables ot too much nesting of local functions.

Helge