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

[Herbert Poetzl <herbert@13thfloor.at>]

On Sun, Jan 22, 2006 at 09:24:27AM -0700, Eric W. Biederman wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
> 
> >> 
> >> A pointer to a task_struct while it kind of sort of works. Is
> >> not a good solution. The problem is that in a lot of cases we
> >> register a pid to get a signal or something similar and then we
> >> never unregister it. So by using a pointer to a trask_struct you
> >> effectively hold the process in memory forever.

> > this is not right. Both the PID and the task struct have the exact
> > same lifetime rules, they HAVE to, to guard against pid reuse
> > problems.

> Yes PIDs reserved for the lifetime of the task_struct (baring minor
> details). There are actually a few races in /proc where it can see the
> task_struct after the pid has been freed (see the pid_alive macro in
> sched.h)
>
> However when used as a reference the number can live as long as you
> want. The classic example is a pid file that can exist even after you
> reboot a machine.
>
> So currently a use of a PID as a reference to processes or process
> groups can last forever. An example of this is the kernel is the
> result of fcntl(fd, F_SETOWN). The session of a tty is similar.
>
> Since the in kernel references have a lifetime that is completely
> different than the lifetime of a process or a PID. It is not safe
> to simply replace such references with a direct reference to a
> task_struct (besides being technically impossible). Adding those
> references could potentially increase the lifespan of a task_struct
> for to the life of the kernel depending on the reference.

well, yes, but wouldn't that be the RightThing(tm) 
anway? because 'referencing' something via a pid, then
letting the task holding the pid go away and even be
replaced by a new one (with the same pid) which then
will get suddenly signaled from somewhere, just because
the pid matches seems very broken to me ...

best,
Herbert

> Eric
> -
> 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/
-
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/