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

[Marc Zyngier <maz@kernel.org>]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel