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:	Fri, 18 Dec 2009 10:28:19 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Zhang Rui <rui.zhang@...el.com>,
	Alan Stern <stern@...land.harvard.edu>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [GIT PULL] PM updates for 2.6.33

On Sun, 2009-12-06 at 22:15 -0800, Linus Torvalds wrote:
> 
> The same is true of the prepare_suspend/suspend split I'm proposing:
> I 
> suspect that for something like USB, it would make most sense to just
> do 
> normal node suspend in prepare_suspend, which would do everything 
> asynchronously. Only USB hub devices would get involved at the later 
> 'suspend()' phase.

Wasn't part of the goal with prepare_suspend() vs. suspend() to handle
the problem of backing store vs the VM ?

IE. Once any device potentially in the VM path is suspended, things like
kmalloc() or gfp() can potentially stall until resume or did we address
that recently ?

Iirc, part of the idea behind prepare_* is that it's safe vs. the above.
Now if you start suspending USB devices at prepare() then you break that
assumption since those could be mass storage with dirty mmap'ed pages on
them.

Now, I'm all for fixing it at the VM/allocator level (if we didn't
already) turning pretty much everything into NO_IO once we start
suspending devices but that's a whole different matter :-)

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ