From: Oleg Nesterov <oleg@redhat.com>
To: Cedric Le Goater <clg@fr.ibm.com>
Cc: Greg Kurz <gkurz@fr.ibm.com>,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
containers@lists.osdl.org, akpm@linux-foundation.org,
xemul@openvz.org
Subject: Re: [PATCH] Introduce ActivePid: in /proc/self/status (v2, was Vpid:)
Date: Thu, 16 Jun 2011 15:06:13 +0200 [thread overview]
Message-ID: <20110616130613.GC19312@redhat.com> (raw)
In-Reply-To: <4DF9F657.7030605@fr.ibm.com>
On 06/16, Cedric Le Goater wrote:
>
> We have a case where a task in a parent pid namespace needs to kill
> another task in a sub pid namespace only knowing its internal pid.
> the latter has been communicated to the parent task through a file or
> a unix socket.
OK, thanks, this partly answers my question... But if they communicate
anyway, it is not clear why the signal is needed.
> This 'ActivePid' information in /proc is not sufficient to identity
> the task, you also need the list of the tasks which are living in
> the pid namespace.
Yes, I see.
> a new kill syscall could be the solution:
>
> int pidns_kill(pid_t init_pid, pid_t some_pid);
>
> where 'init_pid' identifies the namespace and 'some_pid' identifies
> a task in this namespace. this is very specific but why not.
Yes, I also thought about this. Should be trivial.
Or int sys_tell_me_its_pid(pid_t init_pid, pid_t some_pid).
Just in case.... This is hack, yes, but in fact you do not need the
kernel changes to send a signal inside the namespace. You could
ptrace sub_init, and execute the necessary code "inside" the namespace.
Oleg.
next prev parent reply other threads:[~2011-06-16 13:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-15 14:55 [PATCH] Introduce ActivePid: in /proc/self/status (v2, was Vpid:) Greg Kurz
2011-06-15 18:46 ` Oleg Nesterov
2011-06-15 19:08 ` Eric W. Biederman
2011-06-16 11:01 ` Greg Kurz
2011-06-16 12:35 ` Louis Rilling
2011-06-16 13:00 ` Greg Kurz
2011-06-16 13:18 ` Oleg Nesterov
2011-06-16 13:25 ` Louis Rilling
2011-06-16 14:51 ` Oleg Nesterov
2011-06-16 15:08 ` Louis Rilling
2011-06-16 15:01 ` Greg Kurz
2011-06-16 15:27 ` Louis Rilling
2011-06-16 12:42 ` Oleg Nesterov
2011-06-15 19:03 ` Oleg Nesterov
2011-06-16 11:19 ` Greg Kurz
2011-06-16 12:25 ` Cedric Le Goater
2011-06-16 13:06 ` Oleg Nesterov [this message]
2011-06-16 14:25 ` Cedric Le Goater
2011-06-16 15:22 ` Eric W. Biederman
2011-06-16 16:22 ` Oleg Nesterov
2011-06-16 15:07 ` Eric W. Biederman
2011-06-16 15:33 ` Greg Kurz
2011-06-16 16:12 ` Oleg Nesterov
2011-06-16 12:52 ` Oleg Nesterov
2011-06-16 17:54 ` Bryan Donlan
2011-06-20 11:45 ` Greg Kurz
2011-06-20 17:37 ` Bryan Donlan
2011-06-20 22:44 ` Eric W. Biederman
2011-06-22 15:29 ` Greg Kurz
2011-06-23 0:39 ` Eric W. Biederman
2011-06-23 13:43 ` Greg Kurz
2011-06-23 14:37 ` Serge Hallyn
2011-06-22 15:00 ` Greg Kurz
2011-06-22 16:56 ` Bryan Donlan
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=20110616130613.GC19312@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=clg@fr.ibm.com \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=gkurz@fr.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xemul@openvz.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.