On Tue, Mar 22, 2022 at 4:07 AM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> On Mon, Mar 21, 2022 at 4:43 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Sat, Mar 19, 2022 at 3:38 PM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> >
> > > +#ifdef CONFIG_PAGE_SIZE_64KB
> > > +#define THREAD_SIZE_ORDER (0)
> > > +#endif
> > > +
> > > +#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
> > > +#define THREAD_MASK (THREAD_SIZE - 1UL)
> > > +
> >
> > Having a 64KB stack area is rather wasteful. I think you should use a sub-page
> > allocation in this configuration, or possibly disallow 64KB page configuration
> > entirely.
> >
> > Note that you have to use full pages when using CONFIG_VMAP_STACK, but
> > you don't seem to support that at the moment, so allocating only 16KB stacks
> > on a 64KB page config should still work.
> I think using a 16KB stack for all configurations (4KB/16KB/64KB) is
> the simplest way. Right?
Yes, I agree. 16KB is what almost all 64-bit architectures use, though when
you add 32-bit support that can probably be limited to 8KB like most others.
As a side note, you should definitely consider supporting both separate
IRQ stacks and CONFIG_VMAP_STACK if you don't do that already.
Running with those two enabled makes the kernel more robust both
against accidental stack overflow and against malicious code that
attempts to abuse a potential overflow code path.
Arnd
