On Thu, Jul 8, 2021 at 11:30 AM Helge Deller <deller@xxxxxx> wrote: > On 7/7/21 10:39 PM, Arnd Bergmann wrote: > >> [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. But it doesn't use twice as much for large functions at all. The stack frame for a small function is much larger, so you need a larger kernel stack to allow for deely nested call chains, but the frame for single function with large variables is only a bit larger as most of it is used up by those variables. > > 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. Right, and I would consider that a good thing: this warning is for a real (though fairly harmless) bug that has already been fixed with newer toolchains, so anyone that runs into the bug should probably see the warning for it. Doubling the limit would effectively prevent similar bugs from being noticed, and they could be in performance-critical code or cause an actual stack overrun. I can think of two other, more directed workarounds: - change block/Makefile to add -Os to the cflags for this one file in known-broken configurations (parisc with old gcc and -O2), to be removed in a few years when gcc-10 becomes the minimum supported version - add a warning that points to the gcc bug (if someone has a link) when building an affected configuration, and let users decide to either change their setup (using -Os or a newer compiler) or to ignore the warning. > or bad coding, e.g. huge local variables That's what I meant with 'kernel bug'. Arnd