On Mon, Jul 25, 2016 at 02:12:52PM -0300, Thadeu Lima de Souza Cascardo wrote: > On Fri, Jul 22, 2016 at 01:10:33PM -0700, Ben Pfaff wrote: > > On Mon, Jul 18, 2016 at 02:00:20PM -0300, Thadeu Lima de Souza Cascardo > > wrote: > > > This series is a proposal to fix some users of netdev_open and > > > introduce a new behavior for netdev_open when called with a different > > > type than the one already opened. > > > > These seem fine to me. If you post them with signoffs I'll apply them. > > Pending Daniele's comment on my proposal for patch 4, I will send them with > sign-offs. > > This doesn't fix some scenarios involving the routing table, but it > significantly improves the situation. > > Without the series, some successful netdev_open will cause trouble where the > user should have been alerted of the conflict. > > I sent a small series yesterday fixing some of the routing table code, and > there > are yet some other scenarios to fix, which I am working on. But I now have > some > confidence that this series should go in. > > However, some of the decisions I made could be made differently. That's one > reason not to document it as a design decision just yet. But I don't think now > those decisions reflect entire new behavior on the code. Real bugs seem to > improve (though not completely fixed) by this. > > One example I have is when we add a new port with the same name as an existing > system interface, but with a type that is not system. With the routing table > bug > fixed, there will be an open netdev with type system, and as netdev_open will > still succeed, there will be some trouble which I am still investigating, > which > involves a NEWLINK in rtnetlink making bridge_reconfigure to be called again, > causing OVS to consume a lot of CPU.
The problem is caused by the database type conflicting with the ofproto_port type. We open the netdev with type tap, but get a system netdev, try to add it to the datapath, and when we reconfigure the types don't match and we call netdev_remove, which will make the following netdev_open with type tap really create a tap netdev, which will fail because it's there. But if we fail in the earlier case because of a mismatch type when doing the netdev_open, the reconfigure won't happen. The only problem now is that we race with the if-notifier and route table reset, so we try to reconfigure because of a DELLINK, but the route table still has the system netdev open. I will send again with SOB. Cascardo. > > With this series applied, instead, netdev_open will fail and that's it. The > user > will see the failure in the database as "File exists". When the system device > is > removed, there will be a race and the device might not be added as it should, > but that's something else I may work on after I fix some other edges. > > Thanks. > Cascardo. > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
