"Eric W. Biederman" wrote:
>
> Oleg Nesterov <[email protected]> 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.
-
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]
