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:	Thu, 21 Feb 2008 17:05:32 +1100
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Greg KH <gregkh@...e.de>
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.

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?

Regards,

Nigel
--
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