In xlate_send_packet() you aren't allow to hold the xlate_rwlock while > calling xlate_actions(). There are two options to deal with this. > (1) make a new xlate_actions_unsafe() function internal to > ofproto-dpif-xlate which doesn't take the xlate_rwlock, and call that. > (2) Take the xlate_rwlock, compose the xin, release the xlate_rwlock, > and call xlate_actions. >
I'd like to follow the first suggestion, > The ofproto_dpif_send_packet() function isn't thread safe. You aren't > allowed to dereference ofport even to do an ofport->up.ofproto. > Furthermore, incrementing the stats.tx_packets isn't thread safe > without a mutex. The ++ operation isn't atomic. > In the 3/3 patch, I changed the declaration of xlate_actions() to: """ void xlate_actions(struct xlate_in *, struct xlate_out *); """ And ofproto_dpif_monitor_run() will acquire "ovs_rwlock_rdlock(&xlate_rwlock);" before calling ofproto_dpif_send_packet(). So, in this way, I think ofport will be thread safe, since the ofport cannot be destructed without updating the xport. (the stats will not be thread safe though)
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
