OpenVZ Forum - RDF feed
type: channel
items: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
items: Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace

[patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: From: Cedric Le Goater <clg@fr.ibm.com> This patch adds a struct mq_namespace holding the common attributes of the mqueue namespace. The current code is modified to use the default mqueue namespace object 'init_mq_ns' and to prepare the ground for futur dynamic objects. Todo: - use CONFIG_NAMESPACE when next -mm is released Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> --- include/linux/mq_namespace.h | 60 +++++++++++++++++++++++ ipc/mqueue.c | 111 +++++++++++++++++++++++++++---------------- 2 files changed, 130 insertions(+), 41 deletions(-) Index: 2.6.23-rc8-mm2/include/linux/mq_namespace.h =================================================================== --- /dev/null +++ 2.6.23-rc8-mm2/include/linux/mq_namespace.h @@ -0,0 +1,60 @@ +#ifndef _LINUX_MQ_NAMESPACE_H +#define _LINUX_MQ_NAMESPACE_H + +#include <linux/kref.h> + +struct vfsmount; + +struct mq_namespace { + struct kref kref; + struct vfsmount *mnt; + + unsigned int queues_count; + unsigned int queues_max; + unsigned int msg_max; + unsigned int msgsize_max; +}; + +extern struct mq_namespace init_mq_ns; + +#ifdef CONFIG_POSIX_MQUEUE + +#define INIT_MQ_NS(ns) .ns = &init_mq_ns, + +static inline struct mq_namespace *get_mq_ns(struct mq_namespace *ns) +{ + if (ns) + kref_get(&ns->kref); + return ns; +} + +extern struct mq_namespace *copy_mq_ns(unsigned long flags, + struct mq_namespace *old_ns); +extern void free_mq_ns(struct kref *kref); + +static inline void put_mq_ns(struct mq_namespace *ns) +{ + if (ns) + kref_put(&ns->kref, free_mq_ns); +} + +#else + +#define INIT_MQ_NS(ns) + +static inline struct mq_namespace *get_mq_ns(struct mq_namespace *ns) +{ + return ns; +} + +static inline struct mq_namespace *copy_mq_ns(unsigned long flags, + struct mq_namespace *old_ns) +{ + return old_ns; +} + +static inline void put_mq_ns(struct mq_namespace *ns) { } + +#endif /* CONFIG_POSIX_MQUEUE */ + +#endif /* _LINUX_MQ_H */ Index: 2.6.23-rc8-mm2/ipc/mqueue.c ==========================================================…
creator: Cedric Le Goater
date: 2007-10-02T08:46:09-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Cedric, how safe does it intersect with netlinks from network namespace? I see mqueues can send netlink messages, have you checked how safe it is? Thanks, Kirill Cedric Le Goater wrote: > From: Cedric Le Goater <clg@fr.ibm.com> > > This patch adds a struct mq_namespace holding the common attributes > of the mqueue namespace. > > The current code is modified to use the default mqueue namespace > object 'init_mq_ns' and to prepare the ground for futur dynamic > objects. > > Todo: > - use CONFIG_NAMESPACE when next -mm is released > > Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> > --- > include/linux/mq_namespace.h | 60 +++++++++++++++++++++++ > ipc/mqueue.c | 111 +++++++++++++++++++++++++++---------------- > 2 files changed, 130 insertions(+), 41 deletions(-) > > Index: 2.6.23-rc8-mm2/include/linux/mq_namespace.h > =================================================================== > --- /dev/null > +++ 2.6.23-rc8-mm2/include/linux/mq_namespace.h > @@ -0,0 +1,60 @@ > +#ifndef _LINUX_MQ_NAMESPACE_H > +#define _LINUX_MQ_NAMESPACE_H > + > +#include <linux/kref.h> > + > +struct vfsmount; > + > +struct mq_namespace { > + struct kref kref; > + struct vfsmount *mnt; > + > + unsigned int queues_count; > + unsigned int queues_max; > + unsigned int msg_max; > + unsigned int msgsize_max; > +}; > + > +extern struct mq_namespace init_mq_ns; > + > +#ifdef CONFIG_POSIX_MQUEUE > + > +#define INIT_MQ_NS(ns) .ns = &init_mq_ns, > + > +static inline struct mq_namespace *get_mq_ns(struct mq_namespace *ns) > +{ > + if (ns) > + kref_get(&ns->kref); > + return ns; > +} > + > +extern struct mq_namespace *copy_mq_ns(unsigned long flags, > + struct mq_namespace *old_ns); > +extern void free_mq_ns(struct kref *kref); > + > +static inline void put_mq_ns(struct mq_namespace *ns) > +{ > + if (ns) > + kref_put(&ns->kref, free_mq_ns); > +} > + > +#else > + > +#define INIT_MQ_NS(ns) > + > +static inline struct mq_namespace *get_mq_ns(struct mq_namespace *ns) > +{ > + return ns; > +} > + > +static …
creator: dev
date: 2007-10-02T09:06:49-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Hello Kirill, Kirill Korotaev wrote: > Cedric, > > how safe does it intersect with netlinks from network namespace? > I see mqueues can send netlink messages, have you checked how safe it is? a ref is taken on the 'struct sock' in the mq_notify() syscall and the skbuff which will be send to notify the user is also allocated in the mq_notify() syscall. So we should be in the same net namespace when we register the notification and when we notify. I hope the net guys can confirm or we will easily check in the next -lxc patchset which will merge this patchset with netns. however, we have an issue with the signal notification in __do_notify() we could kill a process in a different pid namespace. C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-10-02T10:13:16-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Cedric Le Goater <clg@fr.ibm.com> writes: > Hello Kirill, > > Kirill Korotaev wrote: >> Cedric, >> >> how safe does it intersect with netlinks from network namespace? >> I see mqueues can send netlink messages, have you checked how safe it is? > > a ref is taken on the 'struct sock' in the mq_notify() syscall and the > skbuff which will be send to notify the user is also allocated in the > mq_notify() syscall. So we should be in the same net namespace when we > register the notification and when we notify. > > I hope the net guys can confirm or we will easily check in the next > -lxc patchset which will merge this patchset with netns. > > however, we have an issue with the signal notification in __do_notify() > we could kill a process in a different pid namespace. So I took a quick look at the code as it is (before this patchset) and the taking a reference to a socket and the taking a reference to a struct pid should do the right thing when we intersect with other namespaces. It certainly does not look like a fundamental issue. In practice the patchset as written does conflict with the network namespace work in the net-2.6.24 tree so some adjustments will need to be made. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-10-02T10:59:35-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: >> however, we have an issue with the signal notification in __do_notify() >> we could kill a process in a different pid namespace. > > So I took a quick look at the code as it is (before this patchset) > and the taking a reference to a socket and the taking a reference to > a struct pid should do the right thing when we intersect with other > namespaces. It certainly does not look like a fundamental issue. right. this should be covered when the pid namespace signal handling is complete. kill_pid_info() should fail to send a signal to a sibling or a parent pid namespace. I guess we should add a WARNING() to say that we're attempting to do so. > In practice the patchset as written does conflict with the network > namespace work in the net-2.6.24 tree so some adjustments will need > to be made. I think no more than fixing the CLONE flags in sched.h and the conflicts in nsproxy.c. Thanks ! C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-10-02T12:21:27-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Cedric Le Goater [clg@fr.ibm.com] wrote: | | >> however, we have an issue with the signal notification in __do_notify() | >> we could kill a process in a different pid namespace. | > | > So I took a quick look at the code as it is (before this patchset) | > and the taking a reference to a socket and the taking a reference to | > a struct pid should do the right thing when we intersect with other | > namespaces. It certainly does not look like a fundamental issue. | | right. this should be covered when the pid namespace signal handling is | complete. kill_pid_info() should fail to send a signal to a sibling or | a parent pid namespace. | | I guess we should add a WARNING() to say that we're attempting to do so. Just want to clarify how a signal is sent to a parent ns. A process P1 sets itself up to be notified when a message arrives on a queue. P1 then clones P2 with CLONE_NEWPID. P2 writes to the message queue and thus signals P1 What should the semantics be here ? I guess it makes less sense for two namespaces to be dependent on the same message queue this way. But, if P2 writes to the queue, technically, the queue is not empty, so P1 should be notified, no ? This sounds similar to the SIGIO signal case (F_SETOWN). My understanding was that we would notify whoever was set to receive the notification, even if they were in a parent ns (again my reasoning was its based on the state of a file). IOW, should we change kill_pid_info() ? If the caller can 'see' the 'struct pid' they can signal it. The expectation was that callers would call find_vpid() and thus only see processes in their namespace. | | > In practice the patchset as written does conflict with the network | > namespace work in the net-2.6.24 tree so some adjustments will need | > to be made. | | I think no more than fixing the CLONE flags in sched.h and the conflicts | in nsproxy.c. | | Thanks ! | | C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.…
creator: Sukadev Bhattiprolu
date: 2007-10-02T16:30:20-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Cedric Le Goater <clg@fr.ibm.com> writes: >>> however, we have an issue with the signal notification in __do_notify() >>> we could kill a process in a different pid namespace. >> >> So I took a quick look at the code as it is (before this patchset) >> and the taking a reference to a socket and the taking a reference to >> a struct pid should do the right thing when we intersect with other >> namespaces. It certainly does not look like a fundamental issue. > > right. this should be covered when the pid namespace signal handling is > complete. kill_pid_info() should fail to send a signal to a sibling or > a parent pid namespace. Huh? If we call sys_mq_notify and we become the owner then it should not be a problem to send a signal to us. > I guess we should add a WARNING() to say that we're attempting to do so. I don't understand the problem that you are seeing. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-10-02T17:02:24-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: sukadev@us.ibm.com writes: > Cedric Le Goater [clg@fr.ibm.com] wrote: > | > | >> however, we have an issue with the signal notification in __do_notify() > | >> we could kill a process in a different pid namespace. > | > > | > So I took a quick look at the code as it is (before this patchset) > | > and the taking a reference to a socket and the taking a reference to > | > a struct pid should do the right thing when we intersect with other > | > namespaces. It certainly does not look like a fundamental issue. > > | > | right. this should be covered when the pid namespace signal handling is > | complete. kill_pid_info() should fail to send a signal to a sibling or > | a parent pid namespace. > | > | I guess we should add a WARNING() to say that we're attempting to do so. > > Just want to clarify how a signal is sent to a parent ns. > > A process P1 sets itself up to be notified when a message arrives > on a queue. > > P1 then clones P2 with CLONE_NEWPID. > > P2 writes to the message queue and thus signals P1 > > What should the semantics be here ? > > I guess it makes less sense for two namespaces to be dependent on the same > message queue this way. But, if P2 writes to the queue, technically, the > queue is not empty, so P1 should be notified, no ? Sounds right to me. > This sounds similar to the SIGIO signal case (F_SETOWN). My understanding > was that we would notify whoever was set to receive the notification, even > if they were in a parent ns (again my reasoning was its based on the state > of a file). Yep. > IOW, should we change kill_pid_info() ? If the caller can 'see' the > 'struct pid' they can signal it. The expectation was that callers would > call find_vpid() and thus only see processes in their namespace. Ok. Now I'm concerned. I deliberately designed the initial pid namespace infrastructure to allow mixing like this. Because it is the right thing to do. The expectation is that in general namespaces provide isolation simply because you cannot see and th…
creator: ebiederm
date: 2007-10-02T17:16:46-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Eric W. Biederman wrote: > sukadev@us.ibm.com writes: > >> Cedric Le Goater [clg@fr.ibm.com] wrote: >> | >> | >> however, we have an issue with the signal notification in __do_notify() >> | >> we could kill a process in a different pid namespace. >> | > >> | > So I took a quick look at the code as it is (before this patchset) >> | > and the taking a reference to a socket and the taking a reference to >> | > a struct pid should do the right thing when we intersect with other >> | > namespaces. It certainly does not look like a fundamental issue. >> >> | >> | right. this should be covered when the pid namespace signal handling is >> | complete. kill_pid_info() should fail to send a signal to a sibling or >> | a parent pid namespace. >> | >> | I guess we should add a WARNING() to say that we're attempting to do so. >> >> Just want to clarify how a signal is sent to a parent ns. >> >> A process P1 sets itself up to be notified when a message arrives >> on a queue. >> >> P1 then clones P2 with CLONE_NEWPID. >> >> P2 writes to the message queue and thus signals P1 >> >> What should the semantics be here ? >> >> I guess it makes less sense for two namespaces to be dependent on the same >> message queue this way. But, if P2 writes to the queue, technically, the >> queue is not empty, so P1 should be notified, no ? > > Sounds right to me. It's right for the mqueue namespace but wrong for the pid namespace because we will possibly send a signal to a sibling pid namespace. >> This sounds similar to the SIGIO signal case (F_SETOWN). My understanding >> was that we would notify whoever was set to receive the notification, even >> if they were in a parent ns (again my reasoning was its based on the state >> of a file). > > Yep. > >> IOW, should we change kill_pid_info() ? If the caller can 'see' the >> 'struct pid' they can signal it. The expectation was that callers would >> call find_vpid() and thus only see processes in their namespace. > > Ok. Now I'm concerned. > > I deliber…
creator: Cedric Le Goater
date: 2007-10-03T07:12:56-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: [ I have big fingers this morning and I managed to send this email while typing it ... see below for the end. I should be awake now :) ] > The really challenging case to handle here is what happens if we are > signaling to someone in a sibling pid namespace. What do we set the > parent pid in the siginfo struct to. I think we agreed that 0 (blame > the kernel) is the appropriate pid last time we talked about this. 0 seems appropriate for a signal coming from a parent namespace, yes. but here, we could be sending a signal from a child or sibling namespace. > I'm worried now that the concept of vpid has confused someone. It > still doesn't feel right to me to call one pid value more or less > virtual then any other so the concept of a virtual pid doesn't make > sense to me. The way I have always thought of it is: > - pid_nr(struct pid *) > The pid in the current pid namespace. > - __pid_nr(struct pid_namespace, struct pid *) > The pid in some specified pid namespace. > > With struct pid being defined to be global and doing something > appropriate in all pid namespaces. > > Thinking about this concern that Cedric raises is actually independent > of the mqueue namespace and seems to be totally a pid namespace thing. > Because the only way this happens if we happen to share the mqueue > namespace. (i.e. what we are doing now). Is there a way to catch this general issue (we have the same in sigio) in the kill*(struct pid) routines ? spit a big warning when the current->nsproxy->pid_ns is not a parent ? Thanks ! C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-10-03T07:38:58-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: sukadev@us.ibm.com wrote: > Cedric Le Goater [clg@fr.ibm.com] wrote: > | > | >> however, we have an issue with the signal notification in __do_notify() > | >> we could kill a process in a different pid namespace. > | > > | > So I took a quick look at the code as it is (before this patchset) > | > and the taking a reference to a socket and the taking a reference to > | > a struct pid should do the right thing when we intersect with other > | > namespaces. It certainly does not look like a fundamental issue. > > | > | right. this should be covered when the pid namespace signal handling is > | complete. kill_pid_info() should fail to send a signal to a sibling or > | a parent pid namespace. > | > | I guess we should add a WARNING() to say that we're attempting to do so. > > Just want to clarify how a signal is sent to a parent ns. > > A process P1 sets itself up to be notified when a message arrives > on a queue. > > P1 then clones P2 with CLONE_NEWPID. > > P2 writes to the message queue and thus signals P1 > > What should the semantics be here ? > > I guess it makes less sense for two namespaces to be dependent on the same > message queue this way. But, if P2 writes to the queue, technically, the > queue is not empty, so P1 should be notified, no ? > > This sounds similar to the SIGIO signal case (F_SETOWN). My understanding > was that we would notify whoever was set to receive the notification, even > if they were in a parent ns (again my reasoning was its based on the state > of a file). yes > IOW, should we change kill_pid_info() ? If the caller can 'see' the > 'struct pid' they can signal it. The expectation was that callers would > call find_vpid() and thus only see processes in their namespace. I think we have to decide on some limitations with signals and make sure that we cannot send a signal to a sibling pid namespace. This can occur in some special namespaces unshare configuration which should never be used but to make sure, let's add a big WARNING when we d…
creator: Cedric Le Goater
date: 2007-10-03T07:44:40-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Quoting Cedric Le Goater (clg@fr.ibm.com): > sukadev@us.ibm.com wrote: > > Cedric Le Goater [clg@fr.ibm.com] wrote: > > | > > | >> however, we have an issue with the signal notification in __do_notify() > > | >> we could kill a process in a different pid namespace. > > | > > > | > So I took a quick look at the code as it is (before this patchset) > > | > and the taking a reference to a socket and the taking a reference to > > | > a struct pid should do the right thing when we intersect with other > > | > namespaces. It certainly does not look like a fundamental issue. > > > > | > > | right. this should be covered when the pid namespace signal handling is > > | complete. kill_pid_info() should fail to send a signal to a sibling or > > | a parent pid namespace. > > | > > | I guess we should add a WARNING() to say that we're attempting to do so. > > > > Just want to clarify how a signal is sent to a parent ns. > > > > A process P1 sets itself up to be notified when a message arrives > > on a queue. > > > > P1 then clones P2 with CLONE_NEWPID. > > > > P2 writes to the message queue and thus signals P1 > > > > What should the semantics be here ? > > > > I guess it makes less sense for two namespaces to be dependent on the same > > message queue this way. But, if P2 writes to the queue, technically, the > > queue is not empty, so P1 should be notified, no ? > > > > This sounds similar to the SIGIO signal case (F_SETOWN). My understanding > > was that we would notify whoever was set to receive the notification, even > > if they were in a parent ns (again my reasoning was its based on the state > > of a file). > > yes > > > IOW, should we change kill_pid_info() ? If the caller can 'see' the > > 'struct pid' they can signal it. The expectation was that callers would > > call find_vpid() and thus only see processes in their namespace. > > I think we have to decide on some limitations with signals Yes we do, but > and make sure > that we cannot send a signal to a sibling pid n…
creator: serue
date: 2007-10-03T13:59:55-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: > I think you and Eric (and I) are disagreeing about those limitations. > You take it for granted that a sibling pidns is off limits for signals. > But the signal wasn't sent using a pid, but using a file (in SIGIO > case). So since the fs was shared, the signal should be sent. An > event happened, and the receiver wants to know about it. seen that way I agree. si_code is set to SI_MESGQ, but what do we put in si_pid ? 0 ? we could use the si_errno to pass extra info, like the sending process lives in a // world ... C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-10-03T14:11:27-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Cedric Le Goater <clg@fr.ibm.com> writes: > [ > I have big fingers this morning and I managed to send this email > while typing it ... see below for the end. I should be awake now :) > ] > >> The really challenging case to handle here is what happens if we are >> signaling to someone in a sibling pid namespace. What do we set the >> parent pid in the siginfo struct to. I think we agreed that 0 (blame >> the kernel) is the appropriate pid last time we talked about this. > > 0 seems appropriate for a signal coming from a parent namespace, yes. but > here, we could be sending a signal from a child or sibling namespace. Hmm. I finally see the part of this that is problematic and that we aren't currently handling. > sig_i.si_signo = info->notify.sigev_signo; > sig_i.si_errno = 0; > sig_i.si_code = SI_MESGQ; > sig_i.si_value = info->notify.sigev_value; > sig_i.si_pid = current->tgid; > sig_i.si_uid = current->uid; > > kill_pid_info(info->notify.sigev_signo, &sig_i, info->notify_owner); The filling in of the signal info structure. My gut feel says that should be a struct pid reference. We need to be very careful with the siginfo cases, and si_pid. Unless someone has built a mechanism for dealing with this I haven't seen. I still think the right approach here is that if the pid doesn't map into the target processes pid namespace we should use 0. I also strongly suspect that si_pid should be a struct pid and that we should translate it in the receiving process if possible. > Is there a way to catch this general issue (we have the same in sigio) > in the kill*(struct pid) routines ? spit a big warning when the > current->nsproxy->pid_ns is not a parent ? The SIGIO case is even trickier, although that may count as always coming from the kernel so this doesn't come up. In both cases what is really happening a process in a sibling pid namespace is doing something and the kernel is telling us about it. So sending the signal is legitimate. The difficulty is that the kernel can't e…
creator: ebiederm
date: 2007-10-03T14:32:19-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Cedric Le Goater [clg@fr.ibm.com] wrote: | > I think you and Eric (and I) are disagreeing about those limitations. | > You take it for granted that a sibling pidns is off limits for signals. | > But the signal wasn't sent using a pid, but using a file (in SIGIO | > case). So since the fs was shared, the signal should be sent. An | > event happened, and the receiver wants to know about it. | | seen that way I agree. | | si_code is set to SI_MESGQ, but what do we put in si_pid ? 0 ? | | we could use the si_errno to pass extra info, like the sending process | lives in a // world ... Does the receiver need to know that sender is in a // world ? | | C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2007-10-03T16:56:44-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: sukadev@us.ibm.com writes: > Cedric Le Goater [clg@fr.ibm.com] wrote: > | > I think you and Eric (and I) are disagreeing about those limitations. > | > You take it for granted that a sibling pidns is off limits for signals. > | > But the signal wasn't sent using a pid, but using a file (in SIGIO > | > case). So since the fs was shared, the signal should be sent. An > | > event happened, and the receiver wants to know about it. > | > | seen that way I agree. > | > | si_code is set to SI_MESGQ, but what do we put in si_pid ? 0 ? > | > | we could use the si_errno to pass extra info, like the sending process > | lives in a // world ... > > Does the receiver need to know that sender is in a // world ? What is a // world ? Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-10-03T17:03:26-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Eric W. Biederman [ebiederm@xmission.com] wrote: | sukadev@us.ibm.com writes: | | > Cedric Le Goater [clg@fr.ibm.com] wrote: | > | > I think you and Eric (and I) are disagreeing about those limitations. | > | > You take it for granted that a sibling pidns is off limits for signals. | > | > But the signal wasn't sent using a pid, but using a file (in SIGIO | > | > case). So since the fs was shared, the signal should be sent. An | > | > event happened, and the receiver wants to know about it. | > | | > | seen that way I agree. | > | | > | si_code is set to SI_MESGQ, but what do we put in si_pid ? 0 ? | > | | > | we could use the si_errno to pass extra info, like the sending process | > | lives in a // world ... | > | > Does the receiver need to know that sender is in a // world ? | | What is a // world ? Parallel world/universe :-) I am assuming Cedric used that to refer to a sibling pid ns. | | Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2007-10-03T17:09:30-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: sukadev@us.ibm.com wrote: > Eric W. Biederman [ebiederm@xmission.com] wrote: > | sukadev@us.ibm.com writes: > | > | > Cedric Le Goater [clg@fr.ibm.com] wrote: > | > | > I think you and Eric (and I) are disagreeing about those limitations. > | > | > You take it for granted that a sibling pidns is off limits for signals. > | > | > But the signal wasn't sent using a pid, but using a file (in SIGIO > | > | > case). So since the fs was shared, the signal should be sent. An > | > | > event happened, and the receiver wants to know about it. > | > | > | > | seen that way I agree. > | > | > | > | si_code is set to SI_MESGQ, but what do we put in si_pid ? 0 ? > | > | > | > | we could use the si_errno to pass extra info, like the sending process > | > | lives in a // world ... > | > > | > Does the receiver need to know that sender is in a // world ? probably not. it would mean that the user is container aware. bad idea. > | What is a // world ? > > Parallel world/universe :-) > > I am assuming Cedric used that to refer to a sibling pid ns. yes :) Thanks ! C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-10-04T13:12:39-00:00

Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace
type: item
description: Quoting Cedric Le Goater (clg@fr.ibm.com): > sukadev@us.ibm.com wrote: > > Eric W. Biederman [ebiederm@xmission.com] wrote: > > | sukadev@us.ibm.com writes: > > | > > | > Cedric Le Goater [clg@fr.ibm.com] wrote: > > | > | > I think you and Eric (and I) are disagreeing about those limitations. > > | > | > You take it for granted that a sibling pidns is off limits for signals. > > | > | > But the signal wasn't sent using a pid, but using a file (in SIGIO > > | > | > case). So since the fs was shared, the signal should be sent. An > > | > | > event happened, and the receiver wants to know about it. > > | > | > > | > | seen that way I agree. > > | > | > > | > | si_code is set to SI_MESGQ, but what do we put in si_pid ? 0 ? > > | > | > > | > | we could use the si_errno to pass extra info, like the sending process > > | > | lives in a // world ... > > | > > > | > Does the receiver need to know that sender is in a // world ? > > probably not. it would mean that the user is container aware. bad idea. Remember we don't have to hide the fact that the user is in a container. Just enough to make it convenient, but not to the point of going out of our way to try and hide the fact for no other reason than to hide the fact. > > | What is a // world ? > > > > Parallel world/universe :-) > > > > I am assuming Cedric used that to refer to a sibling pid ns. > > yes :) > > Thanks ! > > C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-10-04T13:32:36-00:00