Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753840AbbGaRvd (ORCPT ); Fri, 31 Jul 2015 13:51:33 -0400 Received: from mail-yk0-f176.google.com ([209.85.160.176]:34067 "EHLO mail-yk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752520AbbGaRvb (ORCPT ); Fri, 31 Jul 2015 13:51:31 -0400 MIME-Version: 1.0 In-Reply-To: <1438353294.20479.7.camel@redhat.com> References: <1438279963-29563-1-git-send-email-joestringer@nicira.com> <1438279963-29563-2-git-send-email-joestringer@nicira.com> <1438353294.20479.7.camel@redhat.com> From: Joe Stringer Date: Fri, 31 Jul 2015 10:51:11 -0700 Message-ID: Subject: Re: [PATCH net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive() To: Hannes Frederic Sowa Cc: Linux Netdev List , Linux Kernel , Pablo Neira Ayuso , Patrick McHardy , Justin Pettit , Pravin Shelar , Andy Zhou , Jesse Gross , Florian Westphal , Thomas Graf Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1581 Lines: 40 On 31 July 2015 at 07:34, Hannes Frederic Sowa wrote: > On Thu, 2015-07-30 at 11:12 -0700, Joe Stringer wrote: >> Signed-off-by: Joe Stringer >> --- >> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/