linux-kernel - Re: [RFC PATCH 0/2] irqchip: GIC: check and clear GIC interupt active status

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: <20140711123507.GE12899@arm.com>
Date:	Fri, 11 Jul 2014 13:35:07 +0100
From:	Will Deacon <will.deacon@....com>
To:	Liu Hua <sdu.liu@...wei.com>
Cc:	"tglx@...utronix.de" <tglx@...utronix.de>,
	"jason@...edaemon.net" <jason@...edaemon.net>,
	"nicolas.pitre@...aro.org" <nicolas.pitre@...aro.org>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"wangnan0@...wei.com" <wangnan0@...wei.com>,
	"liuxueliu.liu@...wei.com" <liuxueliu.liu@...wei.com>,
	"peifeiyue@...wei.com" <peifeiyue@...wei.com>,
	"liusdu@...wei.com" <liusdu@...wei.com>, marc.zyngier@....com
Subject: Re: [RFC PATCH 0/2] irqchip: GIC: check and clear GIC interupt
 active status

[adding Marc]

On Fri, Jul 11, 2014 at 07:46:15AM +0100, Liu Hua wrote:
> For this version of GIC codes, kernel assumes that all the interrupt
> status of GIC is inactive. So the kernel does not check this when 
> booting.
> 
> This is no problem on must sitations. But when kdump is deplayed.
> And a panic occurs when a interrupt is being handled (may be PPI 
> and SPI). We have no chance to write relative bit to GICC_EOIR.
> So this interrupt remains active. And GIC will not deliver this
> type interrupt to cpu interface. And the capture kernel may 
> fail to boot becase of lacking of certain interrupt (such as timer 
> interupt).
> 
> 
> I glanced over the GIC Architecture Specification, but did not 
> find a simple way to deactive state of all interrupts. For GICv1,
> I can only deal with one abnormal interrupt state one time. For 
> GICv2, I can deactive 32 one time.
> 
> 
> So guys, Do you know a better way to do that? 

What happens if, in the crash kernel, you disable the CPU interfaces
(GICC_CTLR.ENABLE) then disable the distributor (GICD_CTLR.ENABLE) before
enabling everything again in the reverse order? Is that enough to cause the
GIC to drop any active states? It's not clear to me from a quick look at
the TRM.

Will
--
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/