Messages in this thread | | | Date | Fri, 8 Jul 2022 17:13:40 +0800 | Subject | Re: [RFC PATCH 2/2] arm64: support HAVE_IRQ_EXIT_ON_IRQ_STACK | From | Qi Zheng <> |
| |
On 2022/7/8 16:52, Arnd Bergmann wrote: > 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.
Yes, and I see that the commit f2c5092190f2 ("arch/*: Disable softirq stacks on PREEMPT_RT.") has been merged into next-20220707, so I will rebase to the next-20220707 and send the next version.
Thank you very much :)
> > Arnd
-- Thanks, Qi
| |