Ben Greear wrote:
Kirill Korotaev wrote:
Patrick McHardy wrote:
I believe OpenVZ stores the current namespace somewhere global,
which avoids passing the namespace around. Couldn't you do this
as well?
yes, we store a global namespace context on current
(can be stored in per-cpu as
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network namespace global variables will be the
Kirill Korotaev wrote:
Patrick McHardy wrote:
I believe OpenVZ stores the current namespace somewhere global,
which avoids passing the namespace around. Couldn't you do this
as well?
yes, we store a global namespace context on current
(can be stored in per-cpu as well).
do you prefer
Jeff Garzik wrote:
Eric W. Biederman wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
David Miller wrote:
I don't accept that we have to add another function argument
to a bunch of core routines just to support this crap,
especially since you give no way to turn it off and get
that function
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 24 Jun 2007 06:58:54 -0600
I am convinced I can keep network namespaces something that is so
trivial and obvious to get right you won't have to pay attention
to them.
Ok then, I'll hold you to
Quoting David Miller ([EMAIL PROTECTED]):
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 11:19:34 -0600
Further and fundamentally all a global achieves is removing the need
for the noise patches where you pass the pointer into the various
functions. For long term
Quoting Jeff Garzik ([EMAIL PROTECTED]):
Eric W. Biederman wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
David Miller wrote:
I don't accept that we have to add another function argument
to a bunch of core routines just to support this crap,
especially since you give no way to turn it off
DM == David Miller [EMAIL PROTECTED] writes:
DM Containers are I believe a step backwards, and we're better than
DM that.
Are there any alternative proposals?
I guess it would be a start if you could run processes with a
different policy table as default. Ideally traffic from those
processes
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 16:56:49 -0600
If the only use was strong isolation which Dave complains about I would
concur that the namespace approach is inappropriate. However there are
a lot other uses.
By
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 15:41:16 -0600
If you want the argument to compile out. That is not a problem at all.
I dropped that part from my patch because it makes infrastructure more
complicated and there
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 24 Jun 2007 06:58:54 -0600
I am convinced I can keep network namespaces something that is so
trivial and obvious to get right you won't have to pay attention
to them.
Ok then, I'll hold you to this when you post the rest of your
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network namespace global variables will be the
loopback device. Which
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network namespace global variables will be the
Patrick McHardy [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network namespace global
Stephen Hemminger [EMAIL PROTECTED] writes:
On Sat, 23 Jun 2007 08:20:40 -0700
Ben Greear [EMAIL PROTECTED] wrote:
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network
Ben Greear [EMAIL PROTECTED] writes:
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network
On Sat, 23 Jun 2007 08:20:40 -0700
Ben Greear [EMAIL PROTECTED] wrote:
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
I believe OpenVZ stores the current namespace somewhere global,
which avoids passing the namespace around. Couldn't you do this
as well?
It sucks. Especially in the corner cases. Think macvlan
with the real network
Patrick McHardy [EMAIL PROTECTED] writes:
Depending upon the data structure it will either be modified to hold
a per entry network namespace pointer or it there will be a separate
copy per network namespace. For large global data structures like
the ipv4 routing cache hash table adding an
On 23.06.2007 19:19, Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Depending upon the data structure it will either be modified to hold
a per entry network namespace pointer or it there will be a separate
copy per network namespace. For large
Eric W. Biederman wrote:
Ben Greear [EMAIL PROTECTED] writes:
Will we be able to have a single application be in multiple name-spaces?
A single application certainly. But then an application can be composed
of multiple processes which can be composed of multiple threads.
In my
Stephen Hemminger wrote:
Will we be able to have a single application be in multiple name-spaces?
That would break the whole point of namespaces...
I was hoping that I could open a socket in one name-space and another in
another name
space, and send traffic between them, within a
Carl-Daniel Hailfinger [EMAIL PROTECTED] writes:
Can one namespace DoS other namespaces' access to the routing cache?
Two scenarios come to mind:
* provoking hash collisions
* lock contention (sorry, haven't checked whether/how we do locking)
My initial expectation is that the protections we
Ben Greear [EMAIL PROTECTED] writes:
Any chance it could allow one to use a single threaded, single process and do
something like
int fd1 = socket(, namespace1);
int fd2 = socket(, namespace2);
Or, maybe a sockopt or similar call to move a socket into a particular
namespace?
I
Eric W. Biederman wrote:
So it may be that we can cover your scenario. However it is just
enough off of the beaten path that I'm not going to worry about it
the first time through. It looks like it is a very small step from
where I am at to where you want to be. So you may be able to cook
up
DM == David Miller [EMAIL PROTECTED] writes:
DM To be honest I think this form of virtualization is a complete
DM waste of time, even the openvz approach.
You are only considering the security values of OpenVZ. Where I work,
OpenVZ and Linux-vserver are used for their ability to cleanly
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 11:19:34 -0600
Further and fundamentally all a global achieves is removing the need
for the noise patches where you pass the pointer into the various
functions. For long term
David Miller wrote:
I don't accept that we have to add another function argument
to a bunch of core routines just to support this crap,
especially since you give no way to turn it off and get
that function argument slot back.
To be honest I think this form of virtualization is a complete
waste
Jeff Garzik [EMAIL PROTECTED] writes:
David Miller wrote:
I don't accept that we have to add another function argument
to a bunch of core routines just to support this crap,
especially since you give no way to turn it off and get
that function argument slot back.
To be honest I think this
Eric W. Biederman wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
David Miller wrote:
I don't accept that we have to add another function argument
to a bunch of core routines just to support this crap,
especially since you give no way to turn it off and get
that function argument slot back.
To
From: Benny Amorsen [EMAIL PROTECTED]
Date: 23 Jun 2007 23:22:38 +0200
Policy routing just doesn't cut it; it's cumbersome to set up, limited
to 256 tables
False.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 15:41:16 -0600
If you want the argument to compile out. That is not a problem at all.
I dropped that part from my patch because it makes infrastructure more
complicated and there appeared to be no gain. However having a type
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 16:56:49 -0600
If the only use was strong isolation which Dave complains about I would
concur that the namespace approach is inappropriate. However there are
a lot other uses.
By your very admission the only appropriate use
Currently all of the prerequisite work for implementing a network
namespace (i.e. virtualization of the network stack with one kernel)
has already been merged or is in the process of being merged.
Therefore it is now time for a bit of high level design review of
the network namespace work and
35 matches
Mail list logo
