On Wed, Jan 25, 2006 at 02:51:22AM -0700, Eric W. Biederman wrote:
> Alan Cox <[email protected]> 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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
