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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Apr 2016 07:41:40 +0100
From:	Paul Burton <paul.burton@...tec.com>
To:	Qais Yousef <qsyousef@...il.com>
CC:	<ralf@...ux-mips.org>, 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 Sat, Apr 02, 2016 at 01:19:03PM +0100, Qais Yousef wrote:
> Hi Paul,
> 
> 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.

Thanks,
    Paul