Nick Andrew wrote: > On Wed, Feb 20, 2008 at 03:23:05PM +0300, Pavel Emelyanov wrote: >>> + This is used by container systems (i.e. vservers). >>> + Tasks in the container are placed in the PID namespace >>> + corresponding to the container, and can only see or >>> + affect processes in the same PID namespace. >> same of one of child namespaces. In other words when you create >> a new pid namespace, you still see the tasks from this new one, >> but the tasks from this one, doesn't see yours :) > > Due to the hierarchial nature, I see. I'm still trying to grok > it. Would it be adequate to describe what a process _cannot_ > do? i.e. > > This is used by container systems (i.e. vservers). > Tasks in the container are placed in the PID namespace > corresponding to the container, and cannot see or > affect processes in any parent PID namespaces.
This looks better. > Or maybe I should say both what it cannot do and what it can, > so readers don't have to use their imagination much :-) I think this would be redundant. > Let's see if I understand how it works with an example. Say we've > got a hierarchy of PID namespaces ... pidA/pidB/pidC and a new > process created in pidC. This new process may have pid 18925 in > pidA, 2263 in pidB and 56 in pidC? Yes. > So if there's another process running in pidC, the first process > may be signaled as pid 56, and if a process is running in pidB > it would be 2263 and not 56. Can a process running in pidB see > all processes running in pidC only with their pidB PIDs? Yes it can. > Now, a process A running in pidA can send a signal to a process > C running in pidC but not vice-versa. Right. > Process C cannot know where the signal came from. Signal delivery is not yet finished, but this is what we plan to do. > Is there any kernel mechanism > which normally would provide that kind of information to > process C but which breaks when PID namespaces are used, > because there's no way to name process A from the context > of pidC ? If the process from pidC receives a signal from pidB or pidA then the appropriate siginfo will (ok - should :)) contain the SI_KERNEL code and zero pid, as if the kernel shoot this process. > Nick. > -- 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/