Re: [PATCH 00/15] irq: remove handle_domain_{irq,nmi}()

Marc Zyngier
2021-10-23T16:07:06Z

On Fri, 22 Oct 2021 16:10:07 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Fri, Oct 22, 2021 at 12:20:31PM +0100, Marc Zyngier wrote:
> > Hi Mark,
> >
> > On Thu, 21 Oct 2021 19:02:21 +0100,
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > >
> > > The handle_domain_{irq,nmi}() functions were oringally intended as a
> > > convenience, but recent rework to entry code across the kernel tree has
> > > demonstrated that they cause more pain than they're worth and prevent
> > > architectures from being able to write robust entry code.
> > >
> > > This series reworks the irq code to remove them, handling the necessary
> > > entry work consistently in entry code (be it architectural or generic).
> >
> > [...]
> >
> > Thanks for going through the pain of putting this together. The
> > couple of nits I mentioned notwithstanding:
> >
> > Reviewed-by: Marc Zyngier <maz@kernel.org>
>
> Thanks!
>
> I've pushed out an updated version to my irq/handle-domain-irq branch
> on kernel.org:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
>
> That has two new patches you suggested:
>
> * irq: mips: simplify bcm6345_l1_irq_handle()
> * irq: unexport handle_irq_desc()
>
> ... which I did not add your Reviewed-by to in case the commit messages
> are garbage or something like that.

I quickly eyeballed the patches, and they look OK to me. Feel free to
add my RB tag to them.

>
> > It'd be good to work out a merging strategy once this has seen a bit
> > of testing.
>
> Conflict-wise, this merges near perfectly against next-20212022 aside
> from a trivial conflict against arch/riscv/Kconfig:
>
> | [mark@lakrids:~/src/linux]% git merge irq/handle-domain-irq
> | Auto-merging arch/riscv/kernel/entry.S
> | Auto-merging arch/riscv/Kconfig
> | CONFLICT (content): Merge conflict in arch/riscv/Kconfig
> | Auto-merging arch/nds32/Kconfig
> | Auto-merging arch/mips/Kconfig
> | Auto-merging arch/csky/Kconfig
> | Auto-merging arch/arm64/Kconfig
> | Auto-merging arch/arm/mach-s3c/irq-s3c24xx.c
> | Auto-merging arch/arm/kernel/entry-armv.S
> | Auto-merging arch/arm/Kconfig
> | Auto-merging arch/arc/Kconfig
> | Automatic merge failed; fix conflicts and then commit the result.
> | [mark@lakrids:~/src/linux]% git diff
> | diff --cc arch/riscv/Kconfig
> | index 77a088d0a7e9,353e28f5f849..000000000000
> | --- a/arch/riscv/Kconfig
> | +++ b/arch/riscv/Kconfig
> | @@@ -62,8 -62,6 +62,11 @@@ config RISC
> | select GENERIC_SCHED_CLOCK
> | select GENERIC_SMP_IDLE_THREAD
> | select GENERIC_TIME_VSYSCALL if MMU && 64BIT
> | ++<<<<<<< HEAD
> | + select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO
> | + select HANDLE_DOMAIN_IRQ
> | ++=======
> | ++>>>>>>> irq/handle-domain-irq
> | select HAVE_ARCH_AUDITSYSCALL
> | select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
> | select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL
>
> ... where the resolution is:
>
> | diff --cc arch/riscv/Kconfig
> | index 77a088d0a7e9,353e28f5f849..000000000000
> | --- a/arch/riscv/Kconfig
> | +++ b/arch/riscv/Kconfig
> | @@@ -62,8 -62,6 +62,7 @@@ config RISC
> | select GENERIC_SCHED_CLOCK
> | select GENERIC_SMP_IDLE_THREAD
> | select GENERIC_TIME_VSYSCALL if MMU && 64BIT
> | + select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO
> | - select HANDLE_DOMAIN_IRQ
> | select HAVE_ARCH_AUDITSYSCALL
> | select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
> | select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL
>
> ... so I reckon we're not set for major pain there unless something new
> appears in arch code in the next few days.
>
> If we can get this onto a branch for linux-next ASAP, and if Linus is
> happy with this having come together a little late, maybe we could queue
> this in tip for v5.16, perhaps after -rc1 to let this soak, or waiting
> to apply the final patch to make it easier to revert the arch changes if
> needed?

I'm happy to route it via the irqchip tree (and ultimately tip) if
nobody objects (which also means getting Acks from the arch maintainers).

The branch would thus see a bit of -next before being sent to Linus.

> I'd like to avoid sitting on this for an entire cycle if possible.

+1.

M.

--
Without deviation from the norm, progress is not possible.