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]

Message-Id: <1233619881.18767.131.camel@pasglop>
Date:	Tue, 03 Feb 2009 11:11:21 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linus Torvalds <torvalds@...ux-foundation.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: PCI PM: Restore standard config registers of all devices early

On Mon, 2009-02-02 at 23:56 +0100, Rafael J. Wysocki wrote:
> * The ACPI_MTX_INTERPRETER mutex needs to be acquired, but we know we won't
>   need that mutex with interrupts off, so presumably we can work around this.

Or just make the mutex code not care when in the late suspend/early
resume. I think that's the right approach and involves no change to ACPI
itself.

> * Memory allocations with GFP_KERNEL are made, which is even worse, because
>   we really shouldn't do that during suspend _at_ _all_, even during the regular
>   ->suspend() with interrupts on, because there's not guarantee that swap will
>   will be available at that time.  So, for the sake of correctness, we should
>   get rid of the GFP_KERNEL from the ACPI code paths executed during
>   suspend-resume anyway.

Well, as I said, this is a problem with more than just ACPI and again, I
don't think the fix is to be done in ACPI itself. The buddy and slab
should basically stick NOIO or ATOMIC to any allocation done after we
started suspending the system.

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/