LKML Archive on
help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: Cedric Le Goater <>
Cc: Linux Kernel Mailing List <>,
Subject: Re: [patch -mm] update mq_notify to use a struct pid
Date: Tue, 12 Sep 2006 10:03:32 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Cedric Le Goater's message of "Tue, 12 Sep 2006 17:37:28 +0200")

Cedric Le Goater <> writes:

> Eric W. Biederman wrote:
> [ ... ]
>> There is also the case that should not come up with signals where
>> we have a pid from a child namespace, that we should also be able to
>> compute the pid for.
> I don't understand how a signal can come from a child pid namespace ?

SIG_CHLD is the only case where I think we will be sending a signal
from the child pid namespace.

Reading pids from the status files in /proc, from a parent namespace,
is another example where we need to deal with the pid of children.

>> In essence I intend to have a list of pid_namespace, pid_t pairs connected
>> to a struct pid that we can look through to find the appropriate pid.
> yes, that's the purpose of pid_nr() I guess.
> This list would contain in nearly all cases a single pair (current pid
> namespace, pid value). It will contain 2 pairs for a task that has unshared
> its pid namespace : a pair for the current pid namespace, that needs to
> allocated when unshare() is called, and one pair for the ancestor pid
> namespace which is already allocated.
> Do you see more ?

I don't see the list getting longer until we get into a nested pid namespaces.

As long as the interface is well defined for the container in a container
case I don't mind having additional restrictions.

I will note that you can get some extremely weird interactions if
you do things like open a file descriptor in the parent pid namespace.
Fork two children each child in a different  pid_namespaces.
fcntl(F_SETOWN) is called in one child, and fcntl(F_GETOWN) is called
in the other child.

So we can't just call BUG_ON, if we have can't find the namespace.
But returning 0 from pid_nr should be fine.


  reply	other threads:[~2006-09-12 16:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-08 16:39 Cedric Le Goater
2006-09-09  2:39 ` Eric W. Biederman
2006-09-11 10:17   ` Cedric Le Goater
2006-09-11 11:09     ` Eric W. Biederman
2006-09-11 14:05       ` Cedric Le Goater
2006-09-11 19:01         ` Eric W. Biederman
2006-09-11 21:53           ` Cedric Le Goater
2006-09-12  1:22             ` Eric W. Biederman
2006-09-12 15:37               ` Cedric Le Goater
2006-09-12 16:03                 ` Eric W. Biederman [this message]
2006-09-12 11:05           ` Herbert Poetzl
2006-09-12 15:14             ` Eric W. Biederman
2006-09-14 20:01             ` [PATCH/RFC] kthread API conversion for dvb_frontend and av7110 Herbert Poetzl
2006-09-14 21:07               ` Cedric Le Goater
2006-09-14 22:10                 ` Herbert Poetzl
2006-11-17  1:50                   ` Andrew de Quincey
2006-11-22 14:56                     ` [Devel] " Cedric Le Goater
2006-11-22 21:32                       ` [v4l-dvb-maintainer] " Andrew de Quincey
2007-01-24 15:47                       ` Cedric Le Goater
2006-12-12 22:58                     ` Eric W. Biederman
2006-12-12 23:13                       ` Herbert Poetzl
2006-12-13 15:55                         ` [Devel] " Cedric Le Goater
2006-09-11 15:48     ` [patch -mm] update mq_notify to use a struct pid Oleg Nesterov

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:

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

  git send-email \ \ \ \ \ \
    --subject='Re: [patch -mm] update mq_notify to use a struct pid' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).