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. 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