Messages in this thread | | | From | Arnd Bergmann <> | Date | Fri, 8 Jul 2022 10:52:25 +0200 | Subject | Re: [RFC PATCH 2/2] arm64: support HAVE_IRQ_EXIT_ON_IRQ_STACK |
| |
On Fri, Jul 8, 2022 at 5:13 AM Qi Zheng <zhengqi.arch@bytedance.com> wrote: > On 2022/7/8 04:55, Arnd Bergmann wrote: > > On Thu, Jul 7, 2022 at 5:00 PM Qi Zheng <zhengqi.arch@bytedance.com> wrote: > >> On 2022/7/7 22:41, Arnd Bergmann wrote: > >>> On Thu, Jul 7, 2022 at 3:38 PM Qi Zheng <zhengqi.arch@bytedance.com> wrote: > >>>> On 2022/7/7 20:49, Arnd Bergmann wrote: > >>> > >>> -asmlinkage void noinstr el1h_64_fiq_handler(struct pt_regs *regs) > >>> +asmlinkage void noinstr el1h_64_irq_handler(struct pt_regs *regs) > >>> +{ > >>> + if (on_thread_stack()) > >>> + call_on_irq_stack(regs, el1_irq); > >> > >> IMO, this can't work. Because el1_interrupt() will invoke > >> arm64_preempt_schedule_irq(), which will cause scheduling on the > >> IRQ stack. > > > > Ah, too bad. I spent some more time looking for a simpler approach, > > but couldn't find one I'm happy with. One idea might be to have > > callback functions for each combinations of irq/fiq with irq/pnmi > > to avoid the nested callback pointers. Not sure if that helps. > > Maybe nested callback pointers are not always a wild beast. ;) > This method does not change much, and we can also conveniently stuff > all kinds of things in do_handler() that we want to run on the IRQ > stack in addition to the handler().
Right, your approach is probably the one that changes the existing code the least. I see that x86 handles this by having call_on_irq_stack() in an inline asm, but this in turn complicates the asm implementation, which is also worth keeping simple.
Arnd
| |