[ovs-discuss] OVERLAPPING DP_PACKETS ctx->xin->payload

Ben Pfaff blp at ovn.org
Thu May 21 19:14:42 UTC 2020


On Thu, May 21, 2020 at 01:28:37PM +0000, Luca Mancini wrote:
> Hi,
> I found out while debugging my new action that ovs overlaps incoming packet payloads and I haven’t found a fix for this. I can’t tell if it’s an OVS bug or if I’m doing something wrong.
> 
> Basically once do_xlate_actions is called and my action is “hit” I attempt to print the packet to gdb using this command:
> Ofproto/ofproto-dpif-xlate.c:
> Compose_foo(ctx):
>                         VLOG_ERR(  "%s",   (char *) dp_packet_get_udp_payload(ctx->xin->packet)    );
> 
> While debugging I saw the function  dp_packet_get_udp_payload(*b) often being called on a previous already used dp_packet pointer (*b), which by debugging even further, I notice it sometimes still contains the previous udp payload received previously, so the call overlaps the 2 payloads. Is this normal behavior? More precise info on how it overlaps can be seen here:
> 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/050090.html
> 
> This is my very trivial setup
> 
>   *   I’m using netcat to send udp payloads between the 2 hosts in the topology h1----s1---h2
>   *   Only flows that contain udp packets go through my foo_Action : “sh ovs-ofctl add-flow s1 in_port=1,dl_type=2048,nw_proto=17,action=foo”
> 
> My end goal is to save these incoming packets in a buffer and if the payloads are wrong then there’s really no point.
> I’m guessing I need a way to free the contents of the pointer ctx->xin->payload, but I haven’t found anything useful in the code, also since ctx->xin->packet is a const I can’t modify it.
> Sorry if this is kind of a repost from my previous query but I’ve tried everything, so any help will be highly appreciated!

Nothing you've presented so far gives me confidence that there's any bug
at all.  The libc memory allocator reuses memory when it's freed, and
doesn't clear it when it's reused.  If the previous packet is longer
than the current one, then some of its bytes are likely to still be
there in memory.


More information about the discuss mailing list