Currently, the revalidator thread may hit segmentation fault when geneve TLV map is updated. It is because we may store the old TLV map (struct tun_table) in the frozen state for recirculation, and we may access the already freed old tun_table in xlate_actions().
This patch update the logic of getting tun_table so that we will use the latest tun_table instead of the frozen one. VMWare-BZ: #2106987 Signed-off-by: Yi-Hung Wei <[email protected]> --- ofproto/ofproto-dpif-xlate.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c index 94e3ddb1376f..5641724a7fa2 100644 --- a/ofproto/ofproto-dpif-xlate.c +++ b/ofproto/ofproto-dpif-xlate.c @@ -7138,10 +7138,14 @@ xlate_actions(struct xlate_in *xin, struct xlate_out *xout) ctx.error = XLATE_INVALID_TUNNEL_METADATA; goto exit; } - } else if (!flow->tunnel.metadata.tab) { + } else if (!flow->tunnel.metadata.tab || xin->frozen_state) { /* If the original flow did not come in on a tunnel, then it won't have * FLOW_TNL_F_UDPIF set. However, we still need to have a metadata * table in case we generate tunnel actions. */ + /* If the translation is from a frozen state, we use the latest + * TLV map to avoid segmentation fault in case the old TLV map is + * replaced by a new one. + * XXX: It is better to abort translation if the table is changed. */ flow->tunnel.metadata.tab = ofproto_get_tun_tab( &ctx.xbridge->ofproto->up); } -- 2.7.4 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
