Kirill Korotaev <[email protected]> writes:
>>>2. Maybe I'm missing something in the discussions, but why is it required? if
>>>you provide fully isolated pid spaces, why do you care for wid?
>>>And how ptrace can work at all if cldstop reports some pid, but child is not
>>>accessiable via ptrace()? and if it doesn't work, what are your changes for?
>> A good question.
>> My pid spaces while isolated from each other are connected together in
>> something that resembles the mount relationship when mounting a filesystem.
> why? is it really required?
A very good question. Supporting waitpid and the normal process management
semantics seems to be a requirement for usability. Completely separate pid
spaces would probably be easier to implement. However then we would need
to implement another interface like waitpid to allow for notifications when
the all of the processes exited.
I have not seen any alternatives being proposed to handle that case.
> doing it this way, you get all the issues with external refs we have with a weak
> isolation, i.e. pspace init can be seen from outside and inside (correct? or am
> I wrong?).
Largely correct. Looking at it from the outside is like looking at a thread
group leader. Sometimes you see the leader sometimes you see the entire
group of processes.
> This makes your approach eseentially the same as ours from
> checkpointing point of view BTW.
Sure. Any attempt to build a general purpose mechanism will suffer from
that. But it is easy enough to drop the external references from the
init processes, and then it's children don't have a chance to get them.
>> The init process of a child pspace is visible in the parent pspace,
>> by it's wid. So you should be able to ptrace pid == 1. The other
>> children remain inaccessible directly.
>> The idea was to do my very best to preserve the unix process tree when
>> constructing a separate pid space
> This more looks like you were trying to make less changes with it and avoid
> fixing issus which can arise when pspaces are fully isolated. Maybe I'm wrong.
It's not sloth. Simply trying to extend the existing API. Not changing
what doesn't need to be changed is a virtue.
But yes fully isolated pid spaces are unmanageable unless you add and API
to deal with it. My api is using the wid to allow a parent process to manage
it essentially like normal.
>> I have to admit I have not yet tested the ptrace corner case, or
>> digested all of it's ramifications. Unless I have messed up somewhere
>> it should just work.
>> This visibility of the child tree by a single pid inside the parent
>> tree is why I think my approach doesn't suffer from most of the
>> problems a completely isolated pid space has.
> which problems? Actually I can't see much problems with isolated pid spaces. And
> isolated pid spaces doesn't require hierarchy, since they are fully isolated.
You also don't find them interesting enough to implement. Or else we are using
the same terms to mean different things.
>> In fact I would even be willing to look at it as a global but
>> hierarchical pid space if that proved an interesting case.
>> So you could have something like pkill(int sig, int which, char *pid_path).
>> Where pid_path is something like "1537/3/58", and which specified
>> what kind of pid you are talking about (thread, pid, process group...)
> And here you need to introduce new non-unix semantics, security checks on
> lookups, etc.
Sure you need to introduce new semantics, etc. But nothing more
than what you already have in OpenVZ. The only necessary difference
is in how you name the process. The target process is still being
manipulated by a process outside of it's scope of existence.
So if the need for doing that is as great as you say it is something
that is doable, and their may be other methods that are easier to work
with.
Personally I only implemented as much manipulation of the init
processes as I did because it came for free. I don't see the need
to manipulate a process in another pid namespace.
Eric
-
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]
