linux-kernel - Re: [PATCH v4 1/5] arm64: Add framework to turn IPI as NMI

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] [day] [month] [year] [list]

Message-ID: <20201013032300.djsxeasxaqbzjhzr@gabell>
Date:   Mon, 12 Oct 2020 23:23:00 -0400
From:   Masayoshi Mizuma <msys.mizuma@...il.com>
To:     Sumit Garg <sumit.garg@...aro.org>
Cc:     Marc Zyngier <maz@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Jason Cooper <jason@...edaemon.net>,
        kgdb-bugreport@...ts.sourceforge.net,
        Douglas Anderson <dianders@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Jason Wessel <jason.wessel@...driver.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        julien.thierry.kdev@...il.com
Subject: Re: [PATCH v4 1/5] arm64: Add framework to turn IPI as NMI

On Mon, Oct 12, 2020 at 05:49:09PM +0530, Sumit Garg wrote:
> Hi Masa,
> 
> On Sat, 10 Oct 2020 at 20:43, Masayoshi Mizuma <msys.mizuma@...il.com> wrote:
> >
> > On Sat, Oct 10, 2020 at 10:34:04AM +0100, Marc Zyngier wrote:
> > > On Sat, 10 Oct 2020 02:58:55 +0100,
> > > Masayoshi Mizuma <msys.mizuma@...il.com> wrote:
> > >
> > > [...]
> > >
> > > > > +void ipi_nmi_setup(int cpu)
> > > > > +{
> > > > > + if (!ipi_desc)
> > > > > +         return;
> > > >
> > > > ipi_nmi_setup() may be called twice for CPU0:
> > > >
> > > >   set_smp_ipi_range => set_smp_ipi_nmi => ipi_nmi_setup
> > > >                     => ipi_setup => ipi_nmi_setup
> > > >
> > > > Actually, I got the following error message via the second ipi_nmi_setup():
> > > >
> > > >   GICv3: Pseudo-NMIs enabled using relaxed ICC_PMR_EL1 synchronisation
> > > >   GICv3: Cannot set NMI property of enabled IRQ 8
> > > >   genirq: Failed to setup NMI delivery: irq 8
> > > >
> 
> Ah, thanks for catching this which I missed during my testing.
> 
> > > > Why don't we have a check to prevent that? Like as:
> > > >
> > > >        if (cpumask_test_cpu(cpu, ipi_desc->percpu_enabled))
> > > >                return;
> > >
> > > That's definitely the wrong thing to do. prepare_nmi_setup() shouldn't
> > > be called twice, and papering over it isn't acceptable.
> >
> > Got it. How about moving ipi_nmi_setup() from ipi_setup() to
> > secondary_start_kernel() ? so that CPU0 can call ipi_nmi_setup() only
> > from set_smp_ipi_nmi().
> >
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -245,6 +245,7 @@ asmlinkage notrace void secondary_start_kernel(void)
> >         notify_cpu_starting(cpu);
> >
> >         ipi_setup(cpu);
> > +       ipi_nmi_setup(cpu);
> >
> >         store_cpu_topology(cpu);
> >         numa_add_cpu(cpu);
> > @@ -966,8 +967,6 @@ static void ipi_setup(int cpu)
> >
> >         for (i = 0; i < nr_ipi; i++)
> >                 enable_percpu_irq(ipi_irq_base + i, 0);
> > -
> > -       ipi_nmi_setup(cpu);
> >  }
> >
> >  #ifdef CONFIG_HOTPLUG_CPU
> >
> 
> IMO, it would be more consistent to keep invocation of ipi_nmi_setup()
> from ipi_setup(). So let me remove other invocation from
> set_smp_ipi_nmi():
> 
> diff --git a/arch/arm64/kernel/ipi_nmi.c b/arch/arm64/kernel/ipi_nmi.c
> index d3aa430..000e457 100644
> --- a/arch/arm64/kernel/ipi_nmi.c
> +++ b/arch/arm64/kernel/ipi_nmi.c
> @@ -87,7 +87,4 @@ void __init set_smp_ipi_nmi(int ipi)
>         ipi_desc = irq_to_desc(ipi);
>         irq_set_status_flags(ipi, IRQ_HIDDEN);
>         ipi_id = ipi;
> -
> -       /* Setup the boot CPU immediately */
> -       ipi_nmi_setup(smp_processor_id());
>  }
> 
> Do let me know if this works for you?

Yes, make sense to me.

Thanks!
Masa