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: <20080221063718.GA25036@suse.de>
Date:	Wed, 20 Feb 2008 22:37:18 -0800
From:	Greg KH <gregkh@...e.de>
To:	Nigel Cunningham <nigel@...el.suspend2.net>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	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>
Subject: Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk.
	Screen becomes green.

On Thu, Feb 21, 2008 at 05:05:32PM +1100, Nigel Cunningham wrote:
> Hi Greg.
>
> Greg KH wrote:
>> On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
>>> Hi.
>>>
>>> Greg KH wrote:
>>>> On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
>>>>> Hi.
>>>>>
>>>>> Matthew Garrett wrote:
>>>>>> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
>>>>>>> - people keep talking about hibernating to an ext3 fs mounted on fuse 
>>>>>>> as a limitation of the freezer. To do that with kexec, you're still 
>>>>>>> going to have to bmap the ext3 fs and pass the block list (in which 
>>>>>>> case we can also do it without kexec) or umount all the ext3/fuse 
>>>>>>> part and remount in the kexec'd kernel. Sort of defeats the purpose, 
>>>>>>> doesn't it?
>>>>>> 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.
>>>> Racy with regards to other things becides trying to suspend a machine?
>>>> If so, what?
>>> That depends on what sort of tangled web you want to weave.
>> Lots of them :)
>> We have tanks running Linux using userspace USB drivers for vision
>> control systems (scary, I know...)  They seem to be successfully running
>> for many years now, and I'm interested in making sure those kinds of
>> things keep working.
>> We also have laser welding robots with userspace PCI drivers in car
>> manufacturing plants.  And other laser cutting robots slicing wood in
>> patterns moving at a rate of over 3 meters a second.  Again, with
>> userspace drivers and Linux.
>> Those users would also love to know of any potential problems you know
>> of for this situation.
>>> Low memory situations is one other situation that occurs to me
>>> quickly, especially (though not only) if your ability to swap were to
>>> depend upon a userspace driver and/or filesystem.
>> Sure, swap over a userspace filesystem or driver isn't a sane idea.  And
>> neither is swaping over NFS over a PPP connection attached to a USB to
>> serial device.  Yes, it's possible, and all in the kernel, but not a
>> wise decision.
>> Other than foolish configurations, if you come up with other issues
>> surrounding userspace drivers that could cause problems, please let me
>> know.
>
> A simple OOM condition isn't an issue? Surely a driver stalling because 
> some of its memory gets swapped out just before it goes to use it would be 
> a problem if it resulted in getting the length of a cut wrong or caused 
> some distorted vision or a late turn :>
>
> Am I missing something? Maybe these drivers mlock memory to avoid those 
> issues or something like that?

I think the mlock their memory to prevent this from happening, it's not
hard when you control all the applications on the box :)

thanks,

greg k-h
--
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/