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: <20070708232819.GJ5401@elf.ucw.cz>
Date:	Mon, 9 Jul 2007 01:28:19 +0200
From:	Pavel Machek <pavel@....cz>
To:	david@...g.hm
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Kyle Moffett <mrmacman_g4@....com>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Subject: Re: hibernation/snapshot design [was Re: [PATCH] Remove process freezer from suspend to RAM pathway]

On Sun 2007-07-08 16:20:46, david@...g.hm wrote:
> On Mon, 9 Jul 2007, Pavel Machek wrote:
> 
> >>>>>Actaully, I'm perfectly fine with that, as long as each task blocked by
> >>>>>the
> >>>>>driver due to suspend has PF_FROZEN (or something similar) set.  Then, 
> >>>>>at
> >>>>>least theoretically, we'll be able to drop the freezer from the suspend
> >>>>>code
> >>>>>path and move it after device_suspend() (or the hibernation-specific
> >>>>>equivalent) for hibernation (in that case there shouldn't be a problem
> >>>>>with
> >>>>>any task waiting on I/O while the freezer is running ;-)).
> >>>>
> >>>>I don't see the need for a freezer for snapshot but that's a different
> >>>>issue. (stop_machine looks good enough to me).
> >>>
> >>>Freezer is not needed for snapshot -- it is needed so that we can
> >>>write out the snapshot to disk without the need for special
> >>>drivers/block/simple-ide-for-suspend.c. (We are doing snapshot, then
> >>>write to disk from userland code in uswsusp).
> >>
> >>instead of trying to freeze most of the system, could you do something
> >>like start a virtual machine sandbox to write the data out, and not let
> >>any userspace other then the sandbox operate?
> >>
> >>you would need to throw away disk buffers so that you don't mix current
> >>pending I/O with I/O from the sandbox, and this would be a visable change
> >>for how suspend is setup, but wouldn't this work?
> >
> >It feels kind of expensive, but yes, we could use another kernel for
> >doing the dump. Kdump people are using that. We could use hypervisor
> >for doing the dump. Xen people are doing that. (But I do not think any
> >of those solutions is suitable for "lets hibernate my notebook" case).
> 
> expensive and reliable beats efficiant and unrelaible.
> 
> why do you say that neither would work for the "lets hibernate my 
> notebook" case?

Both would work. One would eat 8-64MB of your RAM, permanently; second
would eat 5-15% of your cpu, permanently. Not very suitable.

Who says current solution is unreliable?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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