All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@parallels.com>
To: Tejun Heo <tj@kernel.org>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrey Vagin <avagin@parallels.com>,
	James Bottomley <jbottomley@parallels.com>,
	Glauber Costa <glommer@parallels.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Daniel Lezcano <dlezcano@fr.ibm.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: [patch 5/5] elf: Add support for loading ET_CKPT files
Date: Thu, 20 Oct 2011 21:30:44 +0400	[thread overview]
Message-ID: <4EA05AC4.5060706@parallels.com> (raw)
In-Reply-To: <20111020155645.GV25124@google.com>

On 10/20/2011 07:56 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Oct 20, 2011 at 12:33:51PM +0400, Pavel Emelyanov wrote:
>>> To shared kernel data structures.
>>
>> Yet again - keeping shared stuctres self-consistent from which point of view? From
>> the kernel's one - already handled with in-kernel locks. From the userspace one -
>> every single kernel API provides a *way* to do things right, but doesn't provide
>> the fool protection.
> 
> Sigh, no, in exec and related paths, the fact that all other threads
> have been zapped are depended upon and the exec'ing task assumes
> exclusive access to resources which in usual cases would require other
> forms of exclusion.  Maybe there are not too many of them and things
> can definitely be audited and updated but it is pretty intricate down
> there and I just don't see good enough justification here.

The amount of new kernel API is good justification. I've sent the list of what
should we allow to change from user-space for the sake of restore only.

Anyway - let's wait for Cyrill's work done in this area.

>>> IMHO, this is a fundamentally broken approach which isn't even
>>> necessary.  So, FWIW, NACK.
>>
>> It's a pity :( Anyway, as I stated above, we'll try to compare two
>> real implementations, not abstract assumptions.
> 
> Given the state of this thread, I'm pretty skeptical this one can
> survive but, hey, who knows?

That's good to hear that you're still open for discussion.

> Thank you.

Thanks,
Pavel

  parent reply	other threads:[~2011-10-20 17:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-14 11:04 [patch 0/5] [RFC] Checkpoint/restore and Elf extension Cyrill Gorcunov
2011-10-14 11:04 ` [patch 1/5] proc: Introduce the Children: line in /proc/<pid>/status Cyrill Gorcunov
2011-10-14 16:36   ` Tejun Heo
2011-10-14 11:04 ` [patch 2/5] fs: Add do_close helper Cyrill Gorcunov
2011-10-14 11:04 ` [patch 3/5] fs, proc: Add /proc/$pid/tls entry Cyrill Gorcunov
2011-10-14 16:40   ` Tejun Heo
2011-10-14 16:43     ` Cyrill Gorcunov
2011-10-14 11:04 ` [patch 4/5] fs, proc: Add start_data, end_data, start_brk members to /proc/$pid/stat Cyrill Gorcunov
2011-10-14 11:04 ` [patch 5/5] elf: Add support for loading ET_CKPT files Cyrill Gorcunov
2011-10-14 17:10   ` Tejun Heo
2011-10-14 17:33     ` Tejun Heo
2011-10-19  9:03       ` Pavel Emelyanov
2011-10-19 18:22         ` Tejun Heo
2011-10-19 18:49           ` Cyrill Gorcunov
2011-10-19 18:52             ` Cyrill Gorcunov
2011-10-19 18:53               ` Tejun Heo
2011-10-19 19:56           ` Cyrill Gorcunov
2011-10-21 18:26             ` Tejun Heo
2011-10-21 18:36               ` Cyrill Gorcunov
2011-10-21 18:42                 ` Cyrill Gorcunov
2011-10-21 18:48                   ` Tejun Heo
2011-10-21 18:53                     ` Cyrill Gorcunov
2011-10-22  6:34                     ` Pavel Emelyanov
2011-10-20  8:33           ` Pavel Emelyanov
2011-10-20 15:56             ` Tejun Heo
2011-10-20 16:04               ` Cyrill Gorcunov
2011-10-20 17:30               ` Pavel Emelyanov [this message]
2011-10-15 18:59     ` Cyrill Gorcunov
2011-10-21 11:06     ` Glauber Costa
2011-10-21 11:20       ` Cyrill Gorcunov
2011-10-21 11:21         ` Glauber Costa
2011-10-21 11:35           ` Cyrill Gorcunov
2011-10-22 16:49     ` Dan Merillat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EA05AC4.5060706@parallels.com \
    --to=xemul@parallels.com \
    --cc=adobriyan@gmail.com \
    --cc=avagin@parallels.com \
    --cc=dave@linux.vnet.ibm.com \
    --cc=dlezcano@fr.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=glommer@parallels.com \
    --cc=gorcunov@openvz.org \
    --cc=hpa@zytor.com \
    --cc=jbottomley@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.