linux-kernel - Re: Reworking suspend-resume sequence (was: Re: PCI PM: Restore standard config registers of all devices early)

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.0902031313290.3247@localhost.localdomain>
Date:	Tue, 3 Feb 2009 13:18:48 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	"David S. Miller" <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jesse Barnes <jesse.barnes@...el.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andreas Schwab <schwab@...e.de>, Len Brown <lenb@...nel.org>
Subject: Re: Reworking suspend-resume sequence (was: Re: PCI PM: Restore
 standard config registers of all devices early)

On Tue, 3 Feb 2009, Ingo Molnar wrote:
> 
> So i'd still like your tentative Signed-off-by for your patch - it's i think 
> not v2.6.29 material but if it stays problem free in testing we can try it 
> in v2.6.30. If it causes problem it will be clearly bisectable and clearly 
> revertable.

Hmm. You can have my sign-off, because I certainly don't think the patch 
is _wrong_, but I also don't think it's necessarily really worth it unless 
somebody can show a real upside. As mentioned, I don't think this matters 
in practice for the whole MSI suspend issue - doing the "mask()" thing 
feels stupid and certainl;y wasn't what I expected us to do, but it really 
shouldn't matter from an actual behavioural standpoint at all.

And if, as you say, we don't expect to have interrupts spread out across 
CPUs (and with the current io-apic they certainly don't happen - I don't 
know about x2apic) my performance arguments are bogus too.

So the patch probably is the right thing to do, but the upsides are slim 
to nonexistent, and the downside you pointed out of somebody using that 
"handle_edge_irq()" thing with an interrupt that turns out to be level 
after all makes me worry a bit.

But feel free to put it in some experimental branch with my sign-off.

		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/