On 31 July 2015 at 07:34, Hannes Frederic Sowa <han...@redhat.com> wrote: > On Thu, 2015-07-30 at 11:12 -0700, Joe Stringer wrote: >> Signed-off-by: Joe Stringer <joestrin...@nicira.com> >> --- >> net/openvswitch/vport.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c >> index d14f594..baa018f 100644 >> --- a/net/openvswitch/vport.c >> +++ b/net/openvswitch/vport.c >> @@ -475,6 +475,9 @@ void ovs_vport_receive(struct vport *vport, struct >> sk_buff *skb, >> struct sw_flow_key key; >> int error; >> >> + if (!skb->sk || (sock_net(skb->sk) != read_pnet(&vport->dp >> ->net))) >> + skb_scrub_packet(skb, true); >> + >> stats = this_cpu_ptr(vport->percpu_stats); >> u64_stats_update_begin(&stats->syncp); >> stats->rx_packets++; > > In general, this shouldn't be necessary as the packet should already be > scrubbed before they arrive here. > > Could you maybe add a WARN_ON and check how those skbs with conntrack > data traverse the stack? I also didn't understand why make it dependent > on the socket.
OK, sure. One case I could think of is with an OVS internal port in another namespace, directly attached to the bridge. I'll have a play around with WARN_ON and see if I can come up with something more trimmed down. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
