linux-kernel - Re: [PATCH] MIPS: Fix broken malta qemu

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:	Mon, 4 Apr 2016 10:02:23 +0200
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	Paul Burton <paul.burton@...tec.com>
Cc:	Qais Yousef <qsyousef@...il.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: Fix broken malta qemu

On Mon, Apr 04, 2016 at 07:41:40AM +0100, Paul Burton wrote:

> > On 01/04/2016 13:48, Paul Burton wrote:
> > >On Thu, Mar 17, 2016 at 09:08:09PM +0000, Qais Yousef wrote:
> > >>Malta defconfig compiles with GIC on. Hence when compiling for SMP it causes the
> > >>new IPI code to be activated. But on qemu malta there's no GIC causing a
> > >>BUG_ON(!ipidomain) to be hit in mips_smp_ipi_init().
> > >>
> > >>Since in that configuration one can only run a single core SMP (!), skip IPI
> > >>initialisation if we detect that this is the case. It is a sensible behaviour
> > >>to introduce and should keep such possible configuration to run rather than die
> > >>hard unnecessarily.
> > >Hi Qais/Ralf,
> > >
> > >This patch is insufficient I'm afraid. It's entirely possible to use SMP
> > >with multiple VPEs in a single core on Malta boards that don't have a
> > >GIC - we have code handling IPIs in that case guarded by #ifdef
> > >CONFIG_MIPS_MT_SMP in arch/mips/mti-malta/malta-int.c. I think the
> > >BUG_ON needs to be removed entirely, unless that single-core multi-VPE
> > >IPI code is also converted to use an IPI irqdomain.
> > >
> > 
> > I was under the impression that SMP is only supported under GIC and older
> > forms of SMP are deprecated.
> 
> Hi Qais,
> 
> That's incorrect. We're talking about systems that don't have any GIC -
> there are Malta configurations that don't. QEMU is the obvious one, and
> you can break it (at least v2.5.0 which has no GIC) with this patch just
> by using "-cpu 34Kf -smp 2" to show up 2 VPEs. I believe there are also
> real bitfiles (though probably unused these days) that would have the
> same problem.
> 
> > I think the problem you're describing is different to the one this is trying
> > to fix. The right fix for your issue is to make CONFIG_GENERIC_IRQ_IPI
> > selected when CONFIG_MIPS_GIC && !CONFIG_MIPS_MT_SMP.
> > 
> > Would it be easy for you to create such a patch and test it?
> 
> That would be insufficient, since we can have a kernel that includes GIC
> support & CONFIG_MIPS_MT_SMP (SMVP) support and not know whether
> there'll actually be a GIC or multiple VPEs until runtime. So Kconfig
> cannot solve this at compile time.
> 
> I believe that the best thing to do would be to convert the single-core
> MT IPI code to use the IRQ domain stuff you added (which I don't see any
> documentation for & am currently struggling to decipher). But given that
> we're post-merge-window on the way to v4.6 I think the best we can do is
> to just return when there's no IPI domain, rather than BUG_ON. I'll
> submit a patch to do that later this morning.

FYI, Qais' initial fix is in the pull request I sent to Linus yesterday so
any fixes please relative to that patch.

  Ralf