Messages in this thread | | | Date | Sat, 23 Oct 2021 17:06:57 +0100 | From | Marc Zyngier <> | Subject | Re: [PATCH 00/15] irq: remove handle_domain_{irq,nmi}() |
| |
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.
| |