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

Date:	Mon, 4 Apr 2016 09:40:15 +0100
From:	Paul Burton <paul.burton@...tec.com>
To:	Qais Yousef <qsyousef@...il.com>
CC:	Ralf Baechle <ralf@...ux-mips.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	<linux-mips@...ux-mips.org>, <linux-kernel@...r.kernel.org>,
	Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH] MIPS: Fix broken malta qemu

On Mon, Apr 04, 2016 at 09:28:16AM +0100, Qais Yousef wrote:
> On 4 Apr 2016 09:06, "Paul Burton" <paul.burton@...tec.com> wrote:
> >
> > On Mon, Apr 04, 2016 at 10:02:23AM +0200, Ralf Baechle wrote:
> > > FYI, Qais' initial fix is in the pull request I sent to Linus yesterday
> so
> > > any fixes please relative to that patch.
> >
> > Hi Ralf,
> >
> > To late - I already submitted:
> >
> >     https://patchwork.linux-mips.org/patch/13003/
> >
> > I can rebase, but it'll be a revert of Qais' workaround followed by
> > mine & squashed.
> >
> > Thanks,
> >     Paul
> 
> Removing BUG_ON () is the real workaround.

Hi Qais,

They're both workarounds. I think given the point in the cycle that
we're at now it's the best option for now.

> The problem with Malta is that it always selects GIC even when it does
> not have it.

No, that's by design. GIC support can be enabled in Kconfig & the actual
presence of a GIC is detected at runtime. A kernel with GIC support can
run on a system with or without a GIC.

> If you add 2 ipi domains then you need to add a way to tell the platform
> which one to use.

Then we may need some way to do that, or perhaps it'll be OK if we only
register one of them on any given system. As mentioned I haven't really
deciphered this IPI IRQ domain code yet.

> All of the patches I sent were sent for review and were around for a long
> time. There's no need for the passive aggressiveness please because you
> found a problem now. Everything went through the formal process and you and
> everyone had a chance to comment and raise issues out.

Passive agressiveness? Really?

I'm not complaining about your patches having being merged. I haven't
said you failed to follow any process. I didn't have time to review your
patches, and clearly nobody else spotted this either, and a regression
has snuck into mainline. I simply want to fix it. I would also have
liked to find some documentation since it's difficult to figure out how
to add support for the single-core multi-VPE software interrupt case,
but that's the only criticism I've made of the patches & I think it's
just. Please don't be so personal...

> My idea of a fix is to get config dependencies sorted but I'll leave it
> with you and Ralf.

As I tried to explain before and above, we don't have all of the
required information until runtime, so Kconfig cannot solve this. That
won't work.

Thanks,
    Paul