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

[Herbert Poetzl]

On Wed, Jan 25, 2006 at 02:51:22AM -0700, Eric W. Biederman wrote:
> Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> writes:
> 
> > On Maw, 2006-01-24 at 12:26 -0700, Eric W. Biederman wrote:
> 
> >> At least for this first round I think talking about a kpid
> >> as a container, pid pair makes a lot of sense for the moment, as
> >> the other implementations just confuse things.
> >
> > As an abstract object a kpid to me means a single identifier which
> > uniquely identifies the process and which in its component parts be they
> > pointers or not uniquely identifies the process in the container and the
> > container in the system, both correctly refcounted against re-use.
> 
> Correct.
> 
> Currently by using pids internally we are not correctly refcounted
> against reuse.  Nor in the process group case do we even have an
> object off of which we can hang a reference count.
> 
> In the case of a multiple instances of a process space the problem
> is much more acute as we must properly ref count the pid space as
> well.
> 
> Now to further make this fun we have variables like spawnpid in 
> drivers/char/vt_ioctl.c and drivers/char/keyboard.c that
> persist indefinitely.  Which cause problems for most traditional
> reference counting techniques.
> 
> Further in cases where the references persist indefinitely we don't
> want to pin the task_struct in memory indefinitely even after
> the task has exited and it's zombie has been reaped.
> 
> So how do we solve this problem?
> 
> There are two possible approaches I can see to solving this problem.
> 1) Use a non-pointer based kpid and simply accept identifier
>    wrap-around problems with kpids just like we currently accept
>    these problems with pids.

sounds like a poor approach (well similar to the
current one, except that the issues might get more
comples when processes are signalled or referenced
across pid spaces :) ...

anyway, if that would be the aim, it could be done
much simpler by 'just' adding a v/upid field to the
task struct and use that for everything userspace
related (i.e. locating tasks, sending signals, etc)
no need to change the current *pid entries at all

best,
Herbert

> 2) Implement weak references for kpids.
> 
> Semantically a weak reference is a pointer that becomes NULL when the
> object it refers to goes away.
> 
> A couple days ago I conducted an experiment, to see if I could
> implement this in the kernel and surprisingly it is fairly straight
> forward to do.  First you define a weak kpid as a kpid with a
> list_head attached, and whenever you setup a weak kpid you
> register it with the pid hash table.  
> 
> Then in detach_pid when the last reference to the pid goes away, you
> walk the list of weak kpids and you NULL the appropriate entries.
> 
> This seems to solve the reference counting problem neatly and
> without needing to disturb the logic of the existing code.  Even
> outside the context of multiple pid spaces then I think weak
> kpids are desirable.
> 
> Thoughts?
> 
> from kernel/pid.c:
> > void fastcall detach_pid(task_t *task, enum pid_type type)
> > {
> > 	int tmp, nr;
> > 
> > 	nr = __detach_pid(task, type);
> > 	if (!nr)
> > 		return;
> 
> Walk the list of weak kpids here.
> 
> > 
> > 	for (tmp = PIDTYPE_MAX; --tmp >= 0; )
> > 		if (tmp != type && find_pid(tmp, nr))
> > 			return;
> > 
> > 	free_pidmap(nr);
> > }
> 
> 
> Eric
> -
> 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/
-
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/