Re: [RFC PATCH 2/2] arm64: support HAVE_IRQ_EXIT_ON_IRQ_STACK

[Qi Zheng]

On 2022/7/8 16:52, Arnd Bergmann wrote:
> On Fri, Jul 8, 2022 at 5:13 AM Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx> wrote:
> > On 2022/7/8 04:55, Arnd Bergmann wrote:
> > > On Thu, Jul 7, 2022 at 5:00 PM Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx> wrote:
> > > > On 2022/7/7 22:41, Arnd Bergmann wrote:
> > > > > On Thu, Jul 7, 2022 at 3:38 PM Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx> 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