Re: interface name collisions

2009-08-26 Thread Nikos Vassiliadis

Bjoern A. Zeeb wrote:

Robert is currently fixing other if.c bugs for ifindex allocation (proper
locking, reducing races,..), so I am satying away from there to not
interfere with his work but hope to go back there next week, when the if.c
code has settled.


Ah I see, thanks for the information.

Nikos
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"


Re: interface name collisions

2009-08-25 Thread Bjoern A. Zeeb

On Wed, 26 Aug 2009, Nikos Vassiliadis wrote:

Hi,


When an interface is moved from a parent to a child vnet
a check is done. I tried to copy that behavior. Does it
look correct?

--- sys/net/if.c.orig   2009-08-24 15:52:05.0 +0300
+++ sys/net/if.c2009-08-25 23:55:26.0 +0300
@@ -992,6 +992,13 @@
   prison_hold_locked(pr);
   mtx_unlock(&pr->pr_mtx);

+/* Make sure the named iface does not exist in the dst. prison/vnet. 
*/

+   ifp = ifunit(ifname);
+   if (ifp != NULL) {
+   prison_free(pr);
+   return (EEXIST);
+   }
+
   /* Make sure the named iface exists in the source prison/vnet. */
   CURVNET_SET(pr->pr_vnet);
   ifp = ifunit(ifname);   /* XXX Lock to avoid races. */



I hope there would be a comment somewhere that vmomve should be
re-done to fix all this... it was in the commit message:

:: There is some duplicate interface name checking before actually moving
:: the interface between network stacks without locking and thus race
:: prone. Ideally if_vmove will correctly and automagically handle these
:: in the future.

So what you do above replicates this behaviour but doesn't really make
it better as you still may run into the problem only less likely.

Robert is currently fixing other if.c bugs for ifindex allocation (proper
locking, reducing races,..), so I am satying away from there to not
interfere with his work but hope to go back there next week, when the if.c
code has settled.

/bz

--
Bjoern A. Zeeb   What was I talking about and who are you again?
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"


Re: interface name collisions

2009-08-25 Thread Nikos Vassiliadis

Julian Elischer wrote:

We are aware of this.  You are of course also welcome to
make suggestions as to what the correct behavior in these
situations should be.



When an interface is moved from a parent to a child vnet
a check is done. I tried to copy that behavior. Does it
look correct?

--- sys/net/if.c.orig   2009-08-24 15:52:05.0 +0300
+++ sys/net/if.c2009-08-25 23:55:26.0 +0300
@@ -992,6 +992,13 @@
prison_hold_locked(pr);
mtx_unlock(&pr->pr_mtx);

+/* Make sure the named iface does not exist in the dst. prison/vnet. */
+   ifp = ifunit(ifname);
+   if (ifp != NULL) {
+   prison_free(pr);
+   return (EEXIST);
+   }
+
/* Make sure the named iface exists in the source prison/vnet. */
CURVNET_SET(pr->pr_vnet);
ifp = ifunit(ifname);   /* XXX Lock to avoid races. */


Thank you for trying out our new little toy!


Well, thanks for creating this "little toy":)

Nikos
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"


Re: interface name collisions

2009-08-25 Thread Julian Elischer

Nikos Vassiliadis wrote:

Hello,

 It seems that there is no checking for name collisions,
when an interface is claimed from a child vnet.

create ngeth0

lab# ngctl mkpeer eiface ether ether

create test jail

lab# jail -c persist vnet name=test

create nge...@test

lab# jexec test ngctl mkpeer eiface ether ether

claim nge...@test

lab# ifconfig ngeth0 -vnet test
lab# ifconfig ngeth0
ngeth0: flags=8802 metric 0 mtu 1500
ether 00:00:00:00:00:00
ether 00:00:00:00:00:00
lab#


Thanks in advance, Nikos
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"




you are correct (sort of)

The current vnet infrastructure is still under construction
and we have been focusing mostly on the functionality rather
than error handling, so you will find many places where errors
(that are hopefully non fatal) ar enot yet correctly handled.

We are aware of this.  You are of course also welcome to
make suggestions as to what the correct behavior in these
situations should be.


Thank you for trying out our new little toy!
comments and suggestions are always welcome.
Note 8.0 vnet support is for demonstration
purposes only and we do not suggest that it be used in situations
where robust behavior in the face of external or malicios agents
might be a factor.  i.e. it's not at all hardened (that may be an 
understatement).




___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"


interface name collisions

2009-08-25 Thread Nikos Vassiliadis

Hello,

 It seems that there is no checking for name collisions,
when an interface is claimed from a child vnet.

create ngeth0

lab# ngctl mkpeer eiface ether ether

create test jail

lab# jail -c persist vnet name=test

create nge...@test

lab# jexec test ngctl mkpeer eiface ether ether

claim nge...@test

lab# ifconfig ngeth0 -vnet test
lab# ifconfig ngeth0
ngeth0: flags=8802 metric 0 mtu 1500
ether 00:00:00:00:00:00
ether 00:00:00:00:00:00
lab#


Thanks in advance, Nikos
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"