All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Andrew Vagin <avagin@openvz.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Roland McGrath <roland@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [PATCH 0/2] ptrace: add ability to attach a file descriptor to another process
Date: Fri, 16 Dec 2011 08:05:56 -0800	[thread overview]
Message-ID: <20111216160556.GB31770@google.com> (raw)
In-Reply-To: <1324032383-791758-1-git-send-email-avagin@openvz.org>

Hello,

On Fri, Dec 16, 2011 at 01:46:21PM +0300, Andrew Vagin wrote:
> We need this functionality for checkpointing processes.  Now some parts
> are dumped with help PTRACE_SEIZE.  Parasite code is injected to process
> and it collects information.  This code should save data to somewhere.
> I want to suggest a scheme, when a dumper creates file descriptor and
> attaches it to a target process, then execute parasite code, which closes
> this descriptor at the end.
> 
> We can't create unix sockets or open files, because a process may
> be in another namespaces.

I really dislike this.  This doesn't belong in ptrace at all.  With
parasite, you have full control of the process, there gotta be some
other way to talk back.  Can't you create a management process w/ open
UNIX socket when spawning a namespace?  If that doesn't work, wouldn't
letting it dump to filesystem and retrieving it afterwards work?

Thanks.

-- 
tejun

      parent reply	other threads:[~2011-12-16 16:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 10:46 [PATCH 0/2] ptrace: add ability to attach a file descriptor to another process Andrew Vagin
2011-12-16 10:46 ` [PATCH 1/2] fs: add ability to attach and to allocate fd for non current tasks Andrew Vagin
2011-12-16 10:46 ` [PATCH 2/2] ptrace: add ability to attach a file descriptor to another task Andrew Vagin
2011-12-18 18:17   ` Oleg Nesterov
2011-12-16 16:05 ` Tejun Heo [this message]

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=20111216160556.GB31770@google.com \
    --to=tj@kernel.org \
    --cc=avagin@openvz.org \
    --cc=gorcunov@openvz.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=roland@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xemul@parallels.com \
    /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.