linux-kernel - Re: [PATCH] irqchip: gic: Add a cpu map for each GIC instance

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]

Message-ID: <20150730081934.02a6aa99@why.wild-wind.fr.eu.org>
Date:	Thu, 30 Jul 2015 08:19:34 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Jon Hunter <jonathanh@...dia.com>,
	Russell King <linux@....linux.org.uk>,
	"nicolas.pitre@...aro.org" <nicolas.pitre@...aro.org>,
	Jason Cooper <jason@...edaemon.net>,
	LKML <linux-kernel@...r.kernel.org>,
	LAK <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] irqchip: gic: Add a cpu map for each GIC instance

On Wed, 29 Jul 2015 17:10:45 +0100
Thomas Gleixner <tglx@...utronix.de> wrote:

> On Wed, 29 Jul 2015, Jon Hunter wrote:
> 
> Cc'ing Marc ...

Thanks for looping me in.

> 
> > The gic_init_bases() function initialises an array that stores the mapping
> > between the GIC and CPUs. This array is a global array that is
> > unconditionally initialised on every call to gic_init_bases(). Although,
> > it is not common for there to be more than one GIC instance, there are
> > some devices that do support nested GIC controllers and gic_init_bases()
> > can be called more than once.
> > 
> > A 2nd call to gic_init_bases() will clear the previous CPU mapping and
> > will only setup the mapping again for CPU0. This is because for child GIC
> > controllers there is most likely only one recipient of the interrupt.
> > 
> > Fix this by moving the CPU mapping array to the GIC chip data structure
> > so that it is initialised for each GIC instance separately. It is assumed
> > that the bL switcher code is only interested in the root or primary GIC
> > instance.

This feels very odd. If you have a secondary GIC, it is cascaded into
the primary one, and I don't see why you would need to manage the
affinity of the interrupt for the secondary GIC. The only thing that
matters is the affinity of interrupts in the primary one, and this is
what the bl switcher is dealing with.

To me, it looks like the bug is to even try to compute an affinity for
a GIC that is not the primary one, and keeping it around doesn't
seem to make much sense. 

Or am I overlooking something?

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/