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]

Date:	Tue, 3 Feb 2009 19:41:33 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	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>
Subject: Re: Reworking suspend-resume sequence (was: Re: PCI PM: Restore
	standard config registers of all devices early)

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> 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.

Sidenote: one future usecase that moves towards this might be threaded IRQ 
handlers - but it's not a real problem.

For them to run well we want to split IRQ processing into two bits: the 
"fast and atomic" bit, which just goes in, checks which hw generated the 
IRQ, then disables that hw via its device, and then wakes up the irq kernel 
thread to do all the fancy stuff.

[ at this point that 'complete the IRQ' processing might even be done on
  another CPU - if we decide that the irq was requested from a given CPU. So 
  there's even performance advantage to such a splitup. We have not yet 
  built up much local CPU state so we can migrate the work cheaply. ]

But it's not an issue: this too will be driven centrally and disable_irq() 
will obviously inhibit irqs to all handlers on the chain [to stay 
compatible] and not touch the device hw in the suspend case.

So the 'disable the device irq itself' functionality is hidden behind the 
irq flow machinery - and never executed once you've done a widespread 
disable_irq() calls on (almost) all devices.

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