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:	Wed, 05 Aug 2015 11:42:44 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	Anson Huang <Anson.Huang@...escale.com>,
	Anson Huang <b20788@...escale.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"jason@...edaemon.net" <jason@...edaemon.net>
Subject: Re: [PATCH] irqchip/gic: restore global interrupts group settings
 in distributor

On 05/08/15 11:21, Russell King - ARM Linux wrote:
> On Wed, Aug 05, 2015 at 10:59:10AM +0100, Marc Zyngier wrote:
>> On 05/08/15 10:17, Anson Huang wrote:
>>> On Wed, Aug 05, 2015 at 10:12:35AM +0100, Marc Zyngier wrote:
>>> 	I may NOT know the history of enabling secure/non-secure of GIC very well, will spend
>>> some time look into it later, during the upstream of our i.MX6UL's suepnd/resume,
>>> I found patch(19bcd001 ARM: cobble together FIQ backtracing) break kernel resume function. After
>>> looking into the gic driver, I saw the dist_inti set all global interrupts to GROUP 1(non-secure), but in
>>> dist_restore, it does NOT restore those settings, after restoring them, suspend/resume works.
>>
>> Right, this is the code from Russell and Daniel I was talking about. As
>> it says in the commit message:
>>
>>   Cobble the FIQ backtracing together, some of this patch is based on
>>   some of Daniel Thompson's work.  Experimental, and not for submission
>>   yet.
>>
>> So this patch doesn't apply to mainline.
> 
> It's also not intended to be mainline material.  As it says "Experimental"
> and that means "it will probably break some things".  One of the biggest
> issues that this patch has is that if the FIQ IPI gets sent, the rest of
> the system effectively stops until reboot, because we _never_ ack the FIQ
> IPI.  Anyone using this patch in a production system is taking a _very_
> big risk.  No, enabling the other kernel reboot-on-whatever options won't
> save you.
> 
>>> 	Don't we need to make this GIC distributor settings after resume aligned with before suspend?
>>> Before suspend, global interrupts are set to non-secure, but after resume, it is by default set to
>>> secure mode, while cpu controller signal secure interrupts to FIQn, so that is incorrect, not sure
>>> if my understanding is correct, please correct me if I am wrong.
>>
>> You're correct that something has to be done. But this should be done as
>> part of Russell and Daniel FIQ series.
>>
>> Russell, are you willing to carry that patch (or something similar) as
>> part of your series?
> 
> I don't see the worth of doing so.
> 
> My patch is really only meant as a method to stitch the FIQ and NMI
> backtrace code together for my own purposes.  My patch is derived in
> part from my early work and Daniel's patch set, and is definitely
> incomplete.  It's not going to end up in mainline, and it certainly
> has problems, s/r being the least of them.

Understood. At the moment, this series seems to be in -next, which
people interpret as "this is on its way to mainline". Anson definitely
interpreted it this way, and Jon Hunter did the same last week, basing
his own patches on top of this series. That's certainly the way I see
-next too.

Maybe it is worth pulling it out of -next so that it doesn't give people
the wrong impression?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ