Re: interface name collisions
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
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
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
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"