On Tue, Jan 5, 2016 at 3:09 PM, Flavio Fernandes <[email protected]> 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. ;)
I agree with Ben that this still seems like a bug - userspace commands shouldn't be able to crash the kernel, even if they are invalid. The commands you gave are actually the opposite of what I initially thought - they are trying to convert a tap device to an internal device rather than the other way around. However, I'm not sure how this could cause a problem because when the internal device is created, it should fail if there is another device of the same name and then bail out without doing anything else. I tried reproducing it and that does seem to be what happens on my system, so I'm not sure what is happening on yours. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
