Re: [ 00/10] [Suspend2] Modules support.

[Olivier Galibert <galibert@pobox.com>]

On Fri, Feb 03, 2006 at 11:41:29AM +0100, Pavel Machek wrote:
> > I don't even want to think about the interactions
> > between freezing the userspace memory pages and running some processes
> > which may malloc/mmap at the same time.
> 
> There are none. userspace helper is mlocked, and rest of userspace is
> stopped.

Unless the userspace code is as tight as mission-critical RT code, I
don't see how that can work reliably.  Some problems I see:

- What happens if the helper faults in new pages, changes its brk or
mmaps things?  Can we actually swap at that point?  mlocking takes
care of the fault in, not of the rest.

- What happens if the helper reads files?  Where will the pages with
the file data be put?  Are we saving the dcache in the image, and if
yes which state of the dcache?

- What happens if the helper writes files?  What state are we saving,
before starting the helper or after?  Will the fs be in a coherent
state after resume?

- What about IPC?  What if for instance the helper tries to contact
HAL to get some system information?

And if you decide on rules on what the userspace can and can't do, how
do you plan to enforce them?  We have filesystems on the line there,
you don't want them destroyed at resume because the latest version of
kdome-resume-progress-bar thought it was cool to generate an picture
of the desktop at suspend time to show at resume.

The idea of trying to save a state that can be modified dynamically
while you're saving in unpredictable ways makes me very, very afraid.
At least when you're in the kernel you can have complete control over
the machine when needed.

  OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/