linux-kernel - Re: [PATCH 00/15] irq: remove handle_domain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 23 Oct 2021 17:06:57 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     tglx@...utronix.de, linux-kernel@...r.kernel.org,
        aou@...s.berkeley.edu, catalin.marinas@....com,
        deanbo422@...il.com, green.hu@...il.com, guoren@...nel.org,
        jonas@...thpole.se, kernelfans@...il.com,
        linux-arm-kernel@...ts.infradead.org, linux@...linux.org.uk,
        nickhu@...estech.com, palmer@...belt.com, paulmck@...nel.org,
        paul.walmsley@...ive.com, peterz@...radead.org, shorne@...il.com,
        stefan.kristiansson@...nalahti.fi, torvalds@...ux-foundation.org,
        tsbogend@...ha.franken.de, vgupta@...nel.org, will@...nel.org
Subject: Re: [PATCH 00/15] irq: remove handle_domain_{irq,nmi}()

On Fri, 22 Oct 2021 16:10:07 +0100,
Mark Rutland <mark.rutland@....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@....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@...nel.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@...rids:~/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@...rids:~/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.