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.0902031047320.3247@localhost.localdomain>
Date:	Tue, 3 Feb 2009 11:03:04 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jesse Barnes <jesse.barnes@...el.com>
cc:	"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>,
	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:
>
> That said, we've also never had much reason to _care_ deeply, so it's also 
> possible that we do mask things over some path. I didn't actually walk 
> _all_ the paths, and the logic for irq handling has changed enough over 
> the years that I don't know all the paths any more. Maybe we do that 
> explicit mask in some path I missed. We _shouldn't_, but who knows..

Ok, so I decided to actually try to walk it all. Better look at the actual 
code.

Hmm. The _normal_ simple irq handler does this the way I described, but 
for some reason the "handle_edge_irq()" does not. And the reason is 
actually a buglet: it needs to mask things for the "recursive interrupt" 
case.

But that literally just looks like a small implementation detail (the code 
decided to share the code for IRQ_INPROGRESS and IRQ_DISABLED). We should 
fix it, so that you _can_ disable irqs and not have to worry about this 
all.

I'm really not sure why that handle_edge_irq thing uses "ack_and_mask()" 
instead of just "desc->chip->ack()"? I'm also totally flummoxed as to why 
it feels it needs to go all the way out to the device to mask things, 
instead of just masking at an apic level, which is much simpler and faster 
(especially since masking should never happen in practice anyway).

			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/