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. Thanks. -- flavio
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
