Messages in this thread | | | Date | Fri, 8 Jul 2022 11:13:34 +0800 | Subject | Re: [RFC PATCH 2/2] arm64: support HAVE_IRQ_EXIT_ON_IRQ_STACK | From | Qi Zheng <> |
| |
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().
Thanks, Qi
> > Arnd
-- Thanks, Qi
| |