Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[Hubertus Franke]

Eric W. Biederman wrote:
> Hubertus Franke <frankeh@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/