Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Cedric Le Goater]

Eric W. Biederman wrote:

>>>Who do you report as the source of your signal.  
>>
>>I've never dealt with signal enough from userspace to give you a good
>>answer.  Can you explain the mechanics of how you would go about doing
>>this?
> 
> Look at siginfo_t si_pid....

the siginfo is queued when a process is killed and si_pid is updated using
the pidspace of the killing process. Processes parent of a pidspace are of
a special kind : the init kind.

>>>What pid does waitpid return when the parent of your pidspace exits?

Well, a process doing waitpid on a parent of a pidspace, is not part
of that pidspace so waitpid would return the 'real pid'.

Am i getting your point correctly ?

>>>What pid does waitpid return when both processes are in the same pidspace?

hmm, please elaborate.

There are indeed issues when a process is the parent of different
namespaces. This case that should be avoided.

>>>How does /proc handle multiple pid spaces?
>>
>>I'm working on it :)
>>
>>Right now, there's basically a hack in d_hash() to get new dentries for
>>each pidspace.  It is horrible and causes a 50x decrease in performance
>>on some benchmarks like dbench.
>>
>>I think the long-term solution is to make multiple, independent proc
>>mounts, and give each pidspace a separate filesystem view.  That
>>requires some of the nifty new bind mount functionality and a chroot
>>when a new pidspace is created, but I think it works.
> 
> I think you will ultimately want a new filesystem namespace
> not just a chroot, so you can ``virtualize'' your filesystem namespace
> as well.

"virtualize" the mount points but not necessarily the whole filesystem.

> I wonder if you could hook up with the linux vserver project.  The
> requirements are strongly similar, and making a solution that
> would work for everyone has a better chance of getting in.

We feel the same.

C.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/