I think the function xlate_cache_clear() needs be called after
xlate_push_stats() to
avoid xcache->entries use-after-free.
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 85f5792..71b846c 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -2252,6 +2252,7 @@ revalidate_ukey(struct udpif *udpif, struct udpif_key
*ukey,
/* Stats for deleted flows will be attributed upon flow deletion. Skip. */
if (result != UKEY_DELETE) {
xlate_push_stats(ukey->xcache, &push);
+ xlate_cache_clear(ukey->xcache);
ukey->stats = *stats;
ukey->reval_seq = reval_seq;
}
> From: wangyunjian
> Sent: Monday, June 25, 2018 2:19 PM
> To: ovs-discuss@openvswitch.org
> Cc: 'b...@ovn.org' <b...@ovn.org>; Lilijun (Jerry, Cloud Networking)
> <jerry.lili...@huawei.com>
> Subject: [ovs-discuss] a question about ovs crash relationship with learn
> action
>
> I'm running OVS 2.7.0 on a Linux 3.10.0 kernel. I found a ovs crash.
> I doubt it's caused by use-after-free set match->flow = NULL in
> minimatch_destroy function with following stack:
>
> (gdb) bt
> #0 0x00007ff273b71197 in raise () from /usr/lib64/libc.so.6
> #1 0x00007ff273b72888 in abort () from /usr/lib64/libc.so.6
> #2 0x0000000000787289 in PAT_abort ()
> #3 0x00000000007843cd in patchIllInsHandler ()
> #4 <signal handler called>
> #5 0x00000000004cbfae in miniflow_n_values (flow=0x0) at lib/flow.h:540
> #6 0x00000000004cc95f in minimask_hash (mask=0x0, basis=0) at
> lib/classifier-private.h:321
> #7 0x00000000004cf613 in find_subtable (cls=0x38ad6e8, mask=0x0) at
> lib/classifier.c:1406
> #8 0x00000000004cefa7 in classifier_find_rule_exactly (cls=0x38ad6e8,
> target=0x7ff118025500, version=18446744073709551615) at lib/classifier.c:1178
> #9 0x000000000047bcaf in collect_rules_strict (ofproto=0x389bc30,
> criteria=0x7ff1180254f8, rules=0x7ff118025588) at ofproto/ofproto.c:4253
> #10 0x000000000047eba3 in modify_flow_start_strict (ofproto=0x389bc30,
> ofm=0x7ff1180254f0) at ofproto/ofproto.c:5492
> #11 0x0000000000482c9f in ofproto_flow_mod_start (ofproto=0x389bc30,
> ofm=0x7ff1180254f0) at ofproto/ofproto.c:7506
> #12 0x000000000047dc01 in ofproto_flow_mod_learn_start (ofm=0x7ff1180254f0)
> at ofproto/ofproto.c:5088
> #13 0x000000000047dd4b in ofproto_flow_mod_learn (ofm=0x7ff1180254f0,
> keep_ref=true) at ofproto/ofproto.c:5140
> #14 0x00000000004b55d4 in xlate_push_stats_entry (entry=0x7ff118015148,
> stats=0x7ff11d6675f0) at ofproto/ofproto-dpif-xlate-cache.c:130
> #15 0x00000000004b57b6 in xlate_push_stats (xcache=0x7ff1180254a0,
> stats=0x7ff11d6675f0) at ofproto/ofproto-dpif-xlate-cache.c:183
> #16 0x00000000004a312f in revalidate_ukey (udpif=0x38a5260,
> ukey=0x7ff0fc015910, stats=0x7ff11d668260, odp_actions=0x7ff11d66a3d0,
> reval_seq=25145760, recircs=0x7ff11d66a3b0) at
> ofproto/ofproto-dpif-upcall.c:2134
> #17 0x00000000004a3d76 in revalidate (revalidator=0x4cdda08) at
> ofproto/ofproto-dpif-upcall.c:2428
> #18 0x00000000004a0528 in udpif_revalidator (arg=0x4cdda08) at
> ofproto/ofproto-dpif-upcall.c:954
> #19 0x000000000058f811 in ovsthread_wrapper (aux_=0x55088a0) at
> lib/ovs-thread.c:682
> #20 0x00007ff27549adc5 in start_thread () from /usr/lib64/libpthread.so.0
>
> Any idea about this?
> Thanks,
> Yunjian
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
