Messages in this thread | | | Date | Tue, 24 Jan 2006 16:09:24 -0500 | From | Hubertus Franke <> | Subject | Re: RFC [patch 13/34] PID Virtualization Define new task_pid api |
| |
Eric W. Biederman wrote: > Hubertus Franke <frankeh@watson.ibm.com> writes: > > >>In that case, I think we do require the current vpid_to_pid(translations) >>in order to transfer the external user pid ( relative to the namespace ) >>into one that combines namespace (aka container_id) with the external pid. >>Exactly how it is done today. >>What will slightly change is the low level implementations of the >> >>inline pid_t pid_to_vpid_ctx(pid_t pid, const struct task_struct *ctx); >>pid_t __pid_to_vpid_ctx_excp(pid_t pid, int pidspace_id,const struct task_struct >>*ctx); >> >>and reverse. >>The VPID_2_PID and PID_2_VPID still remain at same locations. >> >>Did I get your comments correctly, Eric ?.. > > > Well we may need that. For the moment let's consider putting both > a kpid and upid and the task_struct, and elsewhere. Basically I don't think > translation is necessary in the common case.
OK for discussion purposes no problem .. what ever is the best at the end is the GO. Abstractly speaking, mangling the <container,upid> tuple into the same long int is an implementation detail.
> > However let's look at a single practical case to see how it would need > to be implemnted. > > struct fown_struct. Every file has one and you can modify it both on > a socket with ioctls FIOSETOWN,SIOCSPGRP,FIOGETOWN,SIOCPGRP. And on > a normal file handle with fcntl with FSETOWN, and FGETOWN. > > Since a struct file can be passed between processes in different > pid spaces using unix domain sockets we cannot count on the context > of the signaler to be the same as the context of the setter.
If you follow the patch set, we do distinguish the context case (we might have missed a few here and there, as you already pointed out), but going into the kernel we always take the context of the caller, coming out of the kernel kpid -> upid we do use the appropriate context.
static inline pid_t pid_to_vpid_ctx(pid_t pid, const struct task_struct *ctx)
> > So we need to look at how to handle this case cleanly, and safely.
-- Hubertus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |