On Thu, Jan 05, 2017 at 08:37:26PM -0800, Daniele Di Proietto wrote: > bridge_delete_or_reconfigure() deletes every interface that's not dumped > by OFPROTO_PORT_FOR_EACH(). ofproto_dpif.c:port_dump_next(), used by > OFPROTO_PORT_FOR_EACH, checks if the ofport is in the datapath by > calling port_query_by_name(). If port_query_by_name() returns an error, > the dump is interrupted. If port_query_by_name() returns ENODEV, the > device doesn't exist and the dump can continue. > > port_query_by_name() for the userspace datapath returns ENOENT instead > of ENODEV. This is expected by dpif_port_query_by_name(), but it's not > handled correctly by port_dump_next(). > > This commit fixes the problem by handling ENOENT like ENODEV. > > dpif-netdev handles reconfiguration errors for an interface by deleting > it from the datapath, so it's possible that a device is missing. When this > happens we must make sure that port_dump_next() continues to dump other > devices otherwise they will be deleted and the two layers will have an > inconsistent view. > > The problem was found while developing new code. > > Signed-off-by: Daniele Di Proietto <[email protected]>
I'm not sure whether there's a difference in meaning between ENOENT and ENODEV when it comes from these functions. I wonder whether the dpif layer should translate one of them into the other, for callers' convenience. Acked-by: Ben Pfaff <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
