Adrián Moreno <[email protected]> writes: >> Not fully sure I understand the code path you are referring to, but >> if it’s through >> ovs_dp_notify_wq()->dp_detach_port_notify()->ovs_dp_detach_port(), it >> takes the ovs_lock(). > > The codepath described by Toke is: > (netdev gets unregistered outside of OVS) -> > dp_device_event (under RTNL) -> ovs_netdev_detach_dev() > (IFF_OVS_DATAPATH is cleared) > > Then dp_notify_work is scheduled and it does what you mention: > ovs_dp_notify_wq (lock ovs_mutex) -> dp_detach_port_notify -> > ovs_dp_detach_port > -> ovs_vport_del -> netdev_destroy (at this point > netif_is_ovs_port is false) > > The first part of this codepath (NETDEV_UNREGISTER notification) happens > under RTNL, not under ovs_mutex and it manipulates vport->dev->priv_flags. > > So in theory we could receive the netdev notification while we process a > ovs_vport_cmd_del() command from userspace, which also ends up calling > netdev_destroy.
Yeah, I agree, it's not guaranteed that reading the flags outside the lock will be race free, so re-checking seems safer here (and is also quite cheap). There does seem to be other uses of netif_is_ovs_port() that are outside the RTNL, though, so maybe not such a likely race in practice? Anyway, I'll respin with a comment. -Toke _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
