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

On Tue, 3 Feb 2009, Linus Torvalds wrote:
> 
> So don't worry about putting devices in D3 - disable_irq() will not care 
> AT ALL whether the device is alive or not, and will never try to touch it 
> anyway.

Btw, this is very much the case for MSI irq's in particular. If you ask to 
_mask_ them, it will go to the look up the device list and try to mask 
them (quite frankly, that sounds insane to me, but whatever), but that not 
what the irq layer does for the simple "disable()" case.

It will literally just set the flag, and then even if an interrupt happens 
afterwards, it will just ->ack it, and then call the ->end thing - and 
doesn't need to do anything else in the whole "disable" path because MSI's 
are obviously edge-triggered.

And the ACK is a pure (x2/io)apic thing, and again doesn't actually touch 
the device itself, only the irq controller itself.

So while it is possible in theory that some irq controller ends up trying 
to access the device for disable_irq, I don't think it's ever true in 
reality.

But it's possible that I overlooked some really odd case, of course.

			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/