linux-kernel - 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, 03 Feb 2009 08:07:37 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jesse.barnes@...el.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Andreas Schwab <schwab@...e.de>
Subject: Re: PCI PM: Restore standard config registers of all devices early

> I suspect that we could possibly make ACPI happy by actually leaving 
> interrupts "enabled" in the suspend-late (and early-resume) paths, but 
> with all hardware interrupts actually turned off. But that's really just a 
> "let's fool people by turning off interrupts a different way" thing - it 
> in no way really changes any fundamental issues.

Well, it might be the right approach ... for the simple reason that ACPI
doesn't -really- need external interrupts off ... it's a side effect of
the interpreter using mutexes etc... 

So maybe indeed we should look into doing something like that, in fact,
I quite like it:

 * suspend:

    - suspend devices with IRQs on
    - suspend PICs (ie, mask all interrupts). the main kernel clock 
      source should be kept running tho
    - do the device suspend "late" thing involving ACPI etc..

 * resume:

     the other way around.

Do we still need a real suspend "late" with hard IRQs off in that
scenario ?

Granted, because we are still effectively scheduling etc... we might
have the driver being hit by requests etc... so the suspend_late in the
above setup loses the property of being shielded against that...

> Whether you use "disable_irq() over all interrupts" or "local_irq_save -> 
> local_irq_restore" really doesn't change anything. You cannot do this in a 
> single phase, because that means that you randomly disable interrupts too 
> early (or enable them too late) when drivers still _require_ them.

Well, sort-of. IE. local_irq_save() vs. disable_irq() has a relevant
difference in our context ... the ability to use mutexes, msleep, etc...
which may allow ACPI to operate.

I don't care about ACPI on powerpc, so I'm happy hooking the gating with
irqs off ... but the existing hook isn't in the right place imho.

> Quite frankly, I don't think the second one is workable. It may be the 
> optimal one in theory, but it's never worked for us in practice.

True, it's going to be a pain. However, I still think you're going to
be bitten somewhere if you whack config space back before you called
the appropriate ACPI magic to resume the device, but I may be wrong,
maybe nobody will ever implement really aggressive power management
in their AML ? :-)

Cheers,
Ben.

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