Messages in this thread | | | From | Arnd Bergmann <> | Date | Thu, 26 May 2022 16:05:30 +0200 | Subject | Re: [PATCH v2] riscv: add irq stack support |
| |
On Mon, May 23, 2022 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > > + for_each_possible_cpu(cpu) { > > > > +#ifdef CONFIG_VMAP_STACK > > > > + void *s = __vmalloc_node(IRQ_STACK_SIZE, THREAD_ALIGN, > > > > + THREADINFO_GFP, cpu_to_node(cpu), > > > > + __builtin_return_address(0)); > > > > +#else > > > > + void *s = (void *)__get_free_pages(GFP_KERNEL, get_order(IRQ_STACK_SIZE)); > > > > +#endif > > > > > > On a related topic: is there a reason to still keep the non-VMAP_STACK > > > > irq stack is 16KB on RV64 now, vmalloc doesn't gurantee physical > > continuous pages, I want to keep the stack physical continuous > > characteristic for !VMAP_STACK case. > > I don't understand. What is the benefit of having a physically continuous > stack? If this is required for something, you could still get that with a VMAP > stack by using alloc_pages() to allocate the stack and them using vmap() to > put it into the vmalloc range with appropriate guard pages. > > I think we really want to avoid the case of missing guard pages around > the stack, and eliminate the part where the stack is in the linear map.
I was actually confused here and mixed up a few things: I thought this was about whether to use vmap stacks unconditionally, and this is in fact not even an architecture specific decision, it's a global option as you are probably aware.
Since one can still turn off VMAP_STACK for normal thread stacks, it doesn't make much of a difference whether one can do the same for IRQ stacks. Please just ignore what I said above. I see you already sent a modified v3, and I think either way is fine, feel free to revert back to this method if it makes life easier.
Arnd
| |