Messages in this thread | | | Date | Sun, 15 May 2022 13:20:21 +0800 | From | Jisheng Zhang <> | Subject | Re: [PATCH v2] riscv: add irq stack support |
| |
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) >
| |