On Wed, Jan 6, 2016 at 8:25 PM, Flavio Fernandes <[email protected]> wrote: > > > On Wed, Jan 6, 2016 at 10:58 PM, Jesse Gross <[email protected]> wrote: >> >> 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. > > > Very interesting... what system (kernel/distro) are you using, Jesse? I > wonder if Centos 7.2 is required to make this bug happen. If you think this > is a good idea, I could also try to use the .ko from the the ovs tree > instead > of the kernel module that is part of Centos 7.2.
I just used an old Centos 6 machine that I had laying around along with the kernel module packaged with OVS 2.4. Obviously, this could be affected by different kernel versions in theory although to the best of my knowledge that code hasn't changed in a long time. When I ran the commands that you gave, I got the result which I would normally expect. Changing the type of the tap interface to "internal" results in it disconnecting from the OVS datapath and in the OVS log I see a File Exists error message. If I run ifconfig, the tap port still exists on the system and there doesn't seem to be any problem fetching the stats. I'm not sure why this is different between our two systems. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
