Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids

[Tejun Heo <tj@kernel.org>]

Hello, Pavel.

On Mon, Nov 28, 2011 at 02:38:46PM +0400, Pavel Emelyanov wrote:
> > Hmmm... Any attempt to reserve PIDs without full control over the
> > namespace is futile.  It can never be complete / reliable. 
> 
> Why? What's the _real_ problem with the 
> 
> pid = prctl(PR_RESERVE_PID, 0); /* let the kernel _generate_ a pid for us */
> while (1) {
> 	real_pid = fork();
> 	BUG_ON(pid != real_pid);
> 	if (real_pid == 0)
> 		return do_child();
> 
> 	wait();
> }
> 
> model? Let's temporarily forget about the single reserved pid implementation
> limitation and concentrate on the approach itself.

PID is ns-shared resource.  If you don't have full control over it and
there are other tasks allocating from it, there is no way to reserve
specific pid reliably no matter what you do.  The only things you can
do are - either reserve the pids you want before anyone else takes it
or somehow revoke pids held by other tasks.

Full ns control + set_last_pid essentially gives the ns owner full
reservation + a way to control allocation.

I suppose you're suggesting that with reserve approach, we can also
support recycling pids of existing tasks which is suggested to be
useful for systemd and gdb.

Using this kind of black magic for general system management seems
like a really bad idea to me.  It is extremely obscure and unexpected
and we actually should be looking to dissuade such usage even if the
natural implementation of the mechanism allows for it.

For gdb, it *might* be useful but the usage isn't out there yet and
the suggested mechanism isn't enough to support the suggested usage
(ie. multithread).  We have neither concrete problem or solution.

So, let's do the simple 30 line non-invasive thing now and worry about
the complex problem when it's actually necessary.  It's not like the
ability to set last_pid is gonna interfere with future changes or
anything.

Thanks.

-- 
tejun