RE: [PATCH V4 6/8] riscv: Support HAVE_IRQ_EXIT_ON_IRQ_STACK

[David Laight <David.Laight@ACULAB.COM>]

From: Sebastian Andrzej Siewior
> Sent: 08 September 2022 17:08
> 
> On 2022-09-07 22:25:04 [-0400], guoren@kernel.org 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.

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.

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)