Re: [PATCH 01/23] tref: Implement task references.

[Oleg Nesterov <oleg@tv-sign.ru>]

"Eric W. Biederman" wrote:
> 
> Oleg Nesterov <oleg@tv-sign.ru> writes:
> 
> > I think I have a really good idea.
> >
> > Forget about task ref for a moment. I thinks we can greatly
> > simplify the pids management. We don't PIDTYPE_MAX hash tables,
> > we need only one.
> >
> > The plan:
> >
> >       kill PIDTYPE_TGID
> >       (copy_process/unhash_process need a simple fix)
> 
> Worth doing.  But I think it is an independent problem.

Almost independent, but still we have to do it before we introduce
pid_head. Otherwise next_thread() will be broken, because ->pids[].next
could actually point to pid_head->tasks[].

> pid_head is decent but I am very tempted to call this struct pid.
> Especially if we start getting a lot of pointers to them a simple
> name that makes sense is useful.

Agreed, will rename.

> >       // alloc_pidmap() becomes static,
> >       // do_fork() calls this instead
> >       struct pid_head *alloc_pid(void)
> >       {
>
> Hmm.  I guess that works.  I'm tempted to still return just a pid_t.
> I guess I can't see how the struct pid_head, will be used.

Probably you are right.
 
> There may be another problem here as well.  I don't think we have a lock
> at this point that makes us safe to update the hash table.

Yes,

> If we want to kill the tasklist_lock we also want to add a lock
> to struct pid_head.  Otherwise I don't see how we can safely bump
> the count, above zero.  But using the tasklist_lock for the first
> version shouldn't be a problem.

... and yes. I think we can use pidmap_lock.

Also, find_pid() needs to be rcu safe. I'll try to show the code
tomorrow.

Oleg.