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

From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org,
	aou@eecs.berkeley.edu, catalin.marinas@arm.com,
	deanbo422@gmail.com, green.hu@gmail.com, guoren@kernel.org,
	jonas@southpole.se, kernelfans@gmail.com,
	linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk,
	nickhu@andestech.com, palmer@dabbelt.com, paulmck@kernel.org,
	paul.walmsley@sifive.com, peterz@infradead.org, shorne@gmail.com,
	stefan.kristiansson@saunalahti.fi, torvalds@linux-foundation.org,
	tsbogend@alpha.franken.de, vgupta@kernel.org, will@kernel.org
Subject: Re: [PATCH 00/15] irq: remove handle_domain_{irq,nmi}()
Date: Sat, 23 Oct 2021 17:06:57 +0100	[thread overview]
Message-ID: <87h7d7bu8u.wl-maz@kernel.org> (raw)
In-Reply-To: <20211022151007.GD86184@C02TD0UTHF1T.local>

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