Currently xlate_rwlock is recursively acquired.
(xlate_send_packet -> ofproto_dpif_execute_actions -> xlate_actions)
Due to writer-preference in rwlock implementations, this causes
deadlock if another thread tries to acquire the lock exclusively
behind us.
This change avoids the problem by making xlate_send_packet drop
the lock before calling ofproto_dpif_execute_actions. This is the
simplest fix but opens a race window against port reconfigurations.
Given the way xlate_send_packet is currently used, the race does not
seem a big problem. An alternative would be passing down the
"xlate_rwlock is held" info to ofproto_dpif_execute_actions.
Signed-off-by: YAMAMOTO Takashi <yamam...@valinux.co.jp>
---
ofproto/ofproto-dpif-xlate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 0eadf46..e7e5c0c 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3269,10 +3269,10 @@ xlate_send_packet(const struct ofport_dpif *ofport,
struct ofpbuf *packet)
return EINVAL;
}
output.port = xport->ofp_port;
+ ovs_rwlock_unlock(&xlate_rwlock);
output.max_len = 0;
error = ofproto_dpif_execute_actions(xport->xbridge->ofproto, &flow, NULL,
&output.ofpact, sizeof output,
packet);
- ovs_rwlock_unlock(&xlate_rwlock);
return error;
}
--
1.8.3.1
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
