linux-kernel - Re: [RFC][PATCH 2/2] PM: Rework handling of interrupts during suspend-resume

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: <alpine.LFD.2.00.0902242020120.3111@localhost.localdomain>
Date:	Tue, 24 Feb 2009 20:26:29 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Len Brown <lenb@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][PATCH 2/2] PM: Rework handling of interrupts during
 suspend-resume

On Tue, 24 Feb 2009, Eric W. Biederman wrote:
> The question I was asking is:
> Can we get the broken cpu hotunplug code out of the suspend path?

I think we can move it around. I don't think we can get rid of it.

> If we can get the devices into a low power state and not generating
> interrupts by the time we disable cpus then we do not need to migrate
> irqs from process context and risk hitting the ioapic bugs.

At least one issue is that the actual final "go to sleep" is something 
that has to happen on just one CPU. And I'm pretty sure the others have to 
have gone through the shutdown sequence before that.

And knowing ACPI, the ordering requirements will boil down to something 
insane, like "you have to turn off the other CPU's _before_ you turn off 
some od the core devices, because turning off the other CPU's may involve 
them". 

So if what you would _want_ to do is to move the "turn off CPU's" into the 
very innermost layer, so that different architectures can then decide 
whether they even need to go through that whole thing or not (because 
turning off one core will automatically turn off all the others, simply 
because the power was turned off), I suspect the answer is "no".

So you were probably hoping to never have to have that whole horrible 
issue with moving interrupts around. I'm afraid I'm not seeing it happen. 
But maybe we can have it happen after we've disabled all the non-system 
devices, so that in practice there simply won't be any new interrupts 
coming in any more.

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