Looks good.
On 25 February 2014 16:31, Ben Pfaff <b...@nicira.com> wrote:
> revalidator_sweep__() does not provide udumps, so push_dump_ops() can't
> look them up.
>
> This is my fault: I introduced it during review.
>
> Signed-off-by: Ben Pfaff <b...@nicira.com>
> ---
> ofproto/ofproto-dpif-upcall.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
> index 1622888..e4f81a1 100644
> --- a/ofproto/ofproto-dpif-upcall.c
> +++ b/ofproto/ofproto-dpif-upcall.c
> @@ -1466,12 +1466,17 @@ push_dump_ops(struct revalidator *revalidator,
> }
>
> for (i = 0; i < n_ops; i++) {
> - struct udpif_key *ukey = ops[i].ukey;
> + struct udpif_key *ukey;
>
> - /* Look up the ukey to prevent double-free in case 'ops' contains
> a
> - * given ukey more than once (which can happen if the datapath
> dumps a
> - * given flow more than once). */
> - ukey = ukey_lookup(revalidator, ops[i].udump);
> + /* If there's a udump, this ukey came directly from a datapath
> flow
> + * dump. Sometimes a datapath can send duplicates in flow dumps,
> in
> + * which case we wouldn't want to double-free a ukey, so avoid
> that by
> + * looking up the ukey again.
> + *
> + * If there's no udump then we know what we're doing. */
> + ukey = (ops[i].udump
> + ? ukey_lookup(revalidator, ops[i].udump)
> + : ops[i].ukey);
> if (ukey) {
> ukey_delete(revalidator, ukey);
> }
> --
> 1.7.10.4
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
