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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1233707239.16867.113.camel@pasglop>
Date:	Wed, 04 Feb 2009 11:27:19 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jesse Barnes <jesse.barnes@...el.com>,
	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, 2009-02-03 at 15:18 -0800, Linus Torvalds wrote:

> With ACPI, there is no such thing as a "big issue". There are only tons of 
> small horrid details that. And the "big issue" is that all the small 
> details are insane.

Allright, fair enough :-) Here's my grand plan defeated by the uglyness
of ACPI ... argh ! :-)

In any case, both approach will solve the problem at hand and I'll be
able to move some of that pmac uglyness into the platform hooks.

BTW. Do we want one or two system states ? IE. regarding silently
"upgrading" GFP_KERNEL, I believe it needs to be done in two different
phases. The main suspend loop (after all the prepare() calls complete)
should be done with GFP_KERNEL -> GFP_NOIO, and the last phase with IRQs
really disabled (local_irq_save, aka. sysdev's) could use being done
with GFP_KERNEL -> GFP_ATOMIC.

The later will not be used much, but with the PCI layer now doing
kmalloc GFP_KERNEL all over the place in trivial things like pci_get_*,
I think it's worth it as sysdev's like cpufreq, or other low level arch
bits like memory controller tweaking does involve mucking around with
PCI devices.

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/