Re: [PATCH v2] riscv: add irq stack support

From: Jisheng Zhang <jszhang@kernel.org>
To: David Laight <David.Laight@aculab.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] riscv: add irq stack support
Date: Sun, 15 May 2022 13:20:21 +0800	[thread overview]
Message-ID: <YoCNlWGUp02hgP27@xhacker> (raw)
In-Reply-To: <f7f46323619e4084b4cfc551cdb47dd0@AcuMS.aculab.com>

On Mon, Mar 07, 2022 at 02:32:34PM +0000, David Laight wrote:
> From: Jisheng Zhang
> > Sent: 07 March 2022 14:08
> > Currently, IRQs are still handled on the kernel stack of the current
> > task on riscv platforms. If the task has a deep call stack at the time
> > of interrupt, and handling the interrupt also requires a deep stack,
> > it's possible to see stack overflow.
> > 
> ...
> I'd have thought that a single page is (probably) enough for the
> IRQ stack.
> Certainly its sizing isn't really related to the normal thread
> stack size.
> 
> > From another side, after this patch, it's possible to reduce the
> > THREAD_SIZE to 8KB for RV64 platforms. This is especially useful for
> > those systems with small memory size, e.g the Allwinner D1S platform
> > which is RV64 but only has 64MB DDR.
> 
> Are you sure?
> Is the stack use likely to be very much less than that of x86-64?
> The real problem isn't the stack use of the test you are doing,
> but the horrid worst case stack of some path that has multiple
> 1k+ buffers on stack.

Hi David,

Sorry for delay. I think you are right, at least I should not
put the confusing "it's possible to reduce the THREAD_SIZE to 8KB
for RV64 platforms..." in the commit msg. For one thing, the 8KB
IRQ stack isn't available in the mainline w/o a small patch; For
another, I only do tests on Allwinner D1 platform. So I remove the
section in V3's commit msg.

Thanks

> 
> Apart from compiler fubar (which usually hit KASAN) that stack
> is actually likely to be architecture independent.
> (The difference between 32bit and 64bit is also likely to be
> relatively small - unless there are on-stack arrays of 'long'.)
> 
> For VMAP stacks is there a 'guard' KVA page allocated below
> all of the stacks?
> 64bit systems should have lots of KVA so this shouldn't be
> a problem.
> Then stack overruns will fault and panic rather than trashing
> another data area - which is really hard to debug.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> 