linux-kernel - Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

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: <20080221011032.GA30606@srcf.ucam.org>
Date:	Thu, 21 Feb 2008 01:10:32 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Nigel Cunningham <nigel@...el.suspend2.net>
Cc:	Jesse Barnes <jesse.barnes@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jeff Chua <jeff.chua.linux@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Dave Airlie <airlied@...ux.ie>, linux-acpi@...r.kernel.org,
	suspend-devel List <suspend-devel@...ts.sourceforge.net>,
	Greg KH <gregkh@...e.de>
Subject: Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
> Matthew Garrett wrote:
> >No, with a freezer-based model you can basically *never* suspend to 
> >anything related to FUSE or a userspace USB device or anything involving 
> >userspace iSCSI initiators or whatever. Sure, there are cases where 
> >moving away from the current model doesn't buy you anything, but that 
> >doesn't mean that the current model is a good thing. It's not. The 
> >freezer is a fundamentally broken concept.
> 
> Putting drivers and filesystems in userspace is the fundamentally broken 
> concept. Not just when it comes to the freezer. The whole idea is 
> inherently racy. You can draw silly diagrams about how the freezer 
> supposedly works in LCA slides and spread FUD as much as you like. In 
> the end, though, it's not nearly as hit-and-miss as you say, and 
> replacing the freezer with a kexec based freezer is only going to create 
> as many problems as it removes.

I'm really not interested in debating the matter. There are all sorts of 
potential uses for the freezer, but hibernation isn't one of them. We 
*need* to get rid of the freezer for suspend to RAM (because a band-aid 
to ensure atomicity is kind of pointless when the operation you're 
entering is inherently atomic), and once all the drivers are able to 
deal with that then it's trivial to get rid of it for hibernation as 
well. Arguing that the reality of userspace drivers is broken doesn't 
help here. It's what we have to work with.

> >You're looking at a tiny amount of memory when compared to current 
> >systems. It's really not a problem.
> 
> Please, quantify 'tiny'. In embedded, 5MB can be too much. I've worked 
> on embedded solutions. I'm not pulling problems out of thin air.

Then the in-kernel solution has already lost anyway, and I'm desperately 
unconcerned about out of tree stuff.
-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/