Linux Container Development
 help / color / mirror / Atom feed
From: Greg Kurz <gkurz@fr.ibm.com>
To: Bryan Donlan <bdonlan@gmail.com>
Cc: akpm@linux-foundation.org, containers@lists.osdl.org,
	linux-kernel@vger.kernel.org, serge@hallyn.com,
	daniel.lezcano@free.fr, ebiederm@xmission.com, oleg@redhat.com,
	xemul@openvz.org, Cedric Le Goater <clg@vnet.ibm.com>
Subject: Re: [PATCH] Introduce ActivePid: in /proc/self/status (v2, was Vpid:)
Date: Wed, 22 Jun 2011 17:00:37 +0200	[thread overview]
Message-ID: <1308754837.2959.58.camel@bahia.local> (raw)
In-Reply-To: <BANLkTiknqo0iKry7mjq+mc4iOWj_A_mrrw@mail.gmail.com>

On Mon, 2011-06-20 at 13:37 -0400, Bryan Donlan wrote:
> On Mon, Jun 20, 2011 at 07:45, Greg Kurz <gkurz@fr.ibm.com> wrote:
> > On Thu, 2011-06-16 at 13:54 -0400, Bryan Donlan wrote:
> 
> >> Although getting the in-namespace PID is a useful thing, wouldn't a
> >> truly race-free API be preferable? Any access by PID has the race
> >> condition in which the target process could die, and its PID get
> >> recycled between retrieving the PID and doing something with it.
> >
> > Well the PID is a racy construct when used by another task than the
> > parent... fortunately, most userland code can cope with it ! :)
> 
> That doesn't mean we shouldn't try to fix the race! :)
> 
> >> Perhaps a file-descriptor API would be better, such as something like
> >> this:
> >>
> >> int openpid(int id, int flags);
> >> int rt_sigqueueinfo_fd(int process_fd, int sig, siginfo_t *info);
> >> int sigqueue_fd(int process_fd, int sig, const union sigval value); //
> >> glibc wrapper
> >>
> >
> > The race still exists: openpid() is being passed a PID... Only the
> > parent can legitimately know that this PID identifies a specific
> > unwaited child.
> 
> Yes, the idea would be either the parent process, or the target
> process itself would open the PID, then pass the resulting file
> descriptor to whatever process is actually doing the killing.

Agreed. Such an API would be useful in a scenario where the task to be
killed and the killing task can share a file descriptor: same thread
group or inherited with clone() or connected with an AF_UNIX socket.
My point was just that the racy pid based API will still be needed to
handle all the other scenarios. But maybe it's fine to have two sets of
process handling calls.

> Alternately, one could add additional calls to help identify whether
> the right process was opened (perhaps a call to get a directory handle
> to the corresponding /proc directory?)

-- 
Gregory Kurz                                     gkurz@fr.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)534 638 479                           Fax +33 (0)561 400 420

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

  parent reply	other threads:[~2011-06-22 15:00 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
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 [this message]
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=1308754837.2959.58.camel@bahia.local \
    --to=gkurz@fr.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bdonlan@gmail.com \
    --cc=clg@vnet.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=daniel.lezcano@free.fr \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=serge@hallyn.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox