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.
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/
[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]
