Re: [RFC][PATCH 04/20] pspace: Allow multiple instaces of the process id namespace

[Kirill Korotaev <dev@sw.ru>]

> > I would disagree with you. These discussions IMHO led us to the wrong
> > direction.
> >
> > Can I ask a bunch of questions which are related to other
> > virtualization issues, but which are not addressed by Eric anyhow?
> >
> > - How are you planning to make hierarchical namespaces for such 
> >  resources as IPC? Sockets? Unix sockets?
>
> in the same way as for resources or filesystems -
> management is within the parent, usage within the
> child
So taking example with IPC, you propose the following:
- parent is able to setup limits on segments, sizes, messages etc.
- parent doesn't see child objects itself, i.e. it is unable to share 
segments with a child, send messages to child etc.
Am I correct?

Provided I got it correctly, how does this differ from the situation, 
when one container is granted rights to manage another container?
So where is hierarchy?

Moreover, granting/revoking rights is more fine grained I suppose. And 
it is more secure, since uses the model - allow only things which are 
safe, while heirarchy uses model "allow everything" to do with a child 
and leads to possible DoS.

> > Process tree is hierarchical by it's nature. But what is heirarchical 
> > IPC and other resources?
> for resources it's simple, you have to 'give away'
> a certain share to your children, which in turn will
> enable them to utilize them up to the given amount,
> or (depending on the implementation) up to the total
> amount of the parent.
Again, how does this differ from the situation when one container is 
granted to manage another one? In this case it grant some portion of 
it's resources to anyone he wishes.

Take a look at this from another angle:
You have a child container, which was granted 1/2 of your resources.
But since parent consumed 3/4 of it, child will never be able to get his 
1/2 portion. And child will be unable to find out the reason for 
resources allocation denies.

> (check out ckrm as a proof of concept, and example
> how it should not be done :)
let's be more friendly to each other :)

> > And no one ever told me why we need heierarchy at all. No any _real_
> > use cases. But it's ok.
>
> there are many use cases here, first, the VPS within
> a VPS (of course, not the most useful one, but the
> most obvious one), then there are all kind of test,
> build and security scenarios which can benefit from
> hierarchical structures and 'delegated' administrative
> power (just think web space management)
If you are talking about management, then see my prev paragraph. Rights 
can be granted. Can you provide some other example, what do you want 
from hierarchy?

> > - Eric wants to introduce name spaces, but totally forgots how much
> >  they are tied with each other. IPC refers to netlinks, network refers
> >  to proc and sysctl, etc. It is some rare cases when you will be able
> >  to use namespaces without full OpenVZ/vserver containers. 

> well, we already visited the following:
>
>  - filesystem namespaces (works quite fine completely
>    independant of all other)
it is tightly interconnected with unix sockets, proc, sysfs, ipc, and 
I'm sure something else :)
Herber, Eric, I'm not against namespaces. Actualy OpenVZ doesn't care 
whether we have single container or namespaces, I'm just trying to show 
you, that all of them are not that separate namespaces as you are trying 
to think of them.

>  - pid spaces (again they are quite fine without any
>    other namespace)
only if we remove all these pid uses from fown, netlinks etc.

>  - resource spaces (another one which makes perfect
>    sense to have without the others)
which one? give me an example please.

> the fact that some things like proc or netlink is tied
> to networking and ipc IMHO is just a sign that those
> interfaces need revisiting and proper isolation or
> virtualization ...
it needs virtualization, really. But being virtualized they are still 
tied to the subsystems they were.

> > - How long these namespaces live? And which management interface each
> >  of them will have?
> well, the lifetime of such a space is very likely to
> be at least the time of the users, including all
> created sockets, file-handles, ipc resources, etc ...
So if you have a socket in TCP_FIN_WAIT1 state, which can live long 
time, what do you do with it?
Full example: the process dies, but network space is still alive due to 
such a socket. You won't be able to reuse the address:port until it died.
I'm curios about how do you propose to handle similar issues in separate 
namespaces?

Also as a continuation of this example, if all the processes exited, how 
can you manage namespaces which leaked? where should you go to see these 
sockets if /proc is tightly related to pspace on the task, but there are 
no tasks?

> > So I really hate that we concentrated on discussion of VPIDs,
> > while there are more general and global questions on the whole
> > virtualization itself.
>
>
> well, I was not the one rolling out the 'perfect'
> vpid solution ...
ha ha :) won't start flaming with you.

> > First of all, I don't think syscalls like
> > "do_something and exec" should be introduced.
> Linux-VServer does not have any of those syscalls
> and it works quite well, so why should we need such
> syscalls?
My question is the same! Why?

> I have no problem at all to discuss a general plan
> (hey I though we were already doing so :) or move
> to some other area (like networking :)
Yup. Would be nice to switch to networking, IPC or something like this.

Kirill

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