On Fri, Sep 9, 2022 at 3:30 PM David Laight <David.Laight@xxxxxxxxxx> wrote: > > From: Sebastian Andrzej Siewior > > Sent: 08 September 2022 17:08 > > > > On 2022-09-07 22:25:04 [-0400], guoren@xxxxxxxxxx wrote: > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > > index a07bb3b73b5b..a8a12b4ba1a9 100644 > > > --- a/arch/riscv/Kconfig > > > +++ b/arch/riscv/Kconfig > > > @@ -433,6 +433,14 @@ config FPU > > > > > > If you don't know what to do here, say Y. > > > > > > +config IRQ_STACKS > > > + bool "Independent irq stacks" > > > + default y > > > + select HAVE_IRQ_EXIT_ON_IRQ_STACK > > > + help > > > + Add independent irq stacks for percpu to prevent kernel stack overflows. > > > + We may save some memory footprint by disabling IRQ_STACKS. > > > > Do you really think that it is needed to save memory here? Avoiding > > stack overflows in deep call chains is probably more important than > > saving ~8KiB per CPU. Original riscv is !IRQ_STACKS, I just give a config to make it back. So I would add a CONFIG_EXPERT in the next version. Actually, I have a similar opinion to you, IRQ_STACKS should be force enabled. But as a new feature, we should give users a choice - use or not. > > Particularly if a 64bit build is using small stacks. > > Without static analysis of actual call chain depth it is > really difficult to trim the stack size. > > I'd bet (a few beers) that the deepest stack use in inside > the console print code form a printk() (eg warn_on_once) > in an obscure error path somewhere. > This won't be hit during any normal testing. That means stack overflow would be hidden a lot. But we could enable VMAP_STACK & STACK_LEAK [1]. [1]: https://lore.kernel.org/lkml/20220907014809.919979-1-guoren@xxxxxxxxxx/ > > I think that the analysis objtool does is getting close > to be able to generate the raw data that can be used for > static stack depth analysis. > You need the 'CFI' constants for indirect calls and > some assumptions about depth of recursive calls. > But apart from that the code to process the raw output > isn't that complex. > > A nice task for someone with some spare time. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) -- Best Regards Guo Ren
