On Tue, Jan 05, 2016 at 06:09:22PM -0500, Flavio Fernandes wrote: > Let me start by saying sorry for all the noise on this subject! This is a > wrap up message, I promise. :) > > With help of Flavio L [fbl], I got a better insight on what I did wrong. > When I set the type of the [tap1] interface to > internal, ovsdb was happy to accept it, but that -- of course -- turns out > to 1) be a stupid thing to do and 2) leave > things in a half baked state. > > There is not much in the logs, but as OVS fails to set the type, it frees > up the interface, but that clean up is not > completely done as far as the kernel datapath goes. It then becomes a booby > trap later when VM was created, > as something is still hanging on to its address and calling into > dev_get_stats() with a stale net_device pointer. > > All in all, this is an artifact of a user error and while code could be > made more resilient, it gave me what I > deserved. ;) > > Best, > > -- flaviof > > == > > Example steps of my mistake: > > # /bin/ovs-vsctl add-br br1 > # ip tuntap add mode tap tap1 > # /bin/ovs-vsctl add-port br1 tap1 > # /bin/ovs-vsctl set Interface tap1 type=internal ; # REALLY BAD, > because tap1 already existed as a tun port!!! > # echo $?
I'd still say this is a bug. ovs-vsctl commands shouldn't be able to crash or OOPS the kernel. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
