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: <1225386215.12673.280.camel@nimitz>
Date:	Thu, 30 Oct 2008 10:03:35 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Andrey Mirkin <major@...nvz.org>
Cc:	Oren Laadan <orenl@...columbia.edu>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Cedric Le Goater <clg@...ibm.com>,
	Daniel Lezcano <dlezcano@...ibm.com>,
	Louis Rilling <Louis.Rilling@...labs.com>,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [Devel] Re: [PATCH 0/9] OpenVZ kernel based
	checkpointing/restart

On Thu, 2008-10-30 at 10:02 +0400, Andrey Mirkin wrote:
> Anyway we should ask everyone what they think about user- and kernel- based 
> process creation.
> Dave, Serge, Cedric, Daniel, Louis what do you think about that?

My worry is where a single sys_restart() plus in-kernel process creation
takes us.

In practice, what do we do?  Do we single-thread the entire restore
process?  Or, do we do in-kernel process creation and have multiple
kernel threads trying to read out of different points in the checkpoint
file, trying to restore all their own states in parallel?  Does that
mean that we can't in practice restore from a fd like a pipe or a
network socket?

In the same way, if we *do* create the processes in userspace, how do we
do _that_?  Do we just fork() and sleep() until the kernel comes along
and blows our state away?  How does the kernel process doing the
restoring tell userspace how many things to fork?  How do we match these
new userspace processes up with the ones coming out of the checkpoint
process?

To me, it's just way too early to talk about this stuff.  Both
approaches have their issues, and I'm yet to see the differences
manifested in code so I can really sink my teeth into them

-- Dave

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