Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934202AbcKVSGa (ORCPT ); Tue, 22 Nov 2016 13:06:30 -0500 Received: from mga02.intel.com ([134.134.136.20]:6652 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932768AbcKVSG2 (ORCPT ); Tue, 22 Nov 2016 13:06:28 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,533,1473145200"; d="scan'208";a="789575087" From: "Duyck, Alexander H" To: "edumazet@google.com" , "maan@tuebingen.mpg.de" CC: "linux-kernel@vger.kernel.org" , "ast@kernel.org" , "stable@vger.kernel.org" , "willemb@google.com" , "gregkh@linuxfoundation.org" , "jslaby@suse.cz" , "davem@davemloft.net" , "yibyang@cisco.com" Subject: Re: Linux 4.4.34 Thread-Topic: Linux 4.4.34 Thread-Index: AQHSROHLnoffZaunj0OqG3byajfXn6Dlwf4AgAACAwCAAAfBgIAAAWcAgAACSgCAAABsAIAAAe0A Date: Tue, 22 Nov 2016 18:03:31 +0000 Message-ID: <1479837808.681.169.camel@intel.com> References: <20161121092855.GA20976@kroah.com> <20161122165912.GA19939@tuebingen.mpg.de> <20161122170654.GA20022@kroah.com> <1479836511.681.165.camel@intel.com> <20161122175504.GD19939@tuebingen.mpg.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.134.2.24] Content-Type: text/plain; charset="utf-8" Content-ID: <97795F200888844B895729F5D9C17379@intel.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id uAMI6h7c029910 Content-Length: 1692 Lines: 53 On Tue, 2016-11-22 at 09:56 -0800, Eric Dumazet wrote: > On Tue, Nov 22, 2016 at 9:55 AM, Andre Noll wrote: > > > > On Tue, Nov 22, 09:46, Eric Dumazet wrote > > > > > > This is an aliasing problem. > > > Tom code is hard to read and understand. > > > > > > Andre, could you try : > > > > > > diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c > > > index 69e4463a4b1b..b045980faaea 100644 > > > --- a/net/core/flow_dissector.c > > > +++ b/net/core/flow_dissector.c > > > @@ -157,6 +157,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb, > > > memcpy(key_eth_addrs, ð->h_dest, sizeof(*key_eth_addrs)); > > > } > > > > > > + barrier(); > > > again: > > > switch (proto) { > > > case htons(ETH_P_IP): { > > > > This patch on top of v4.4.34 makes no difference: I'm still getting > > the panic in eth_type_trans(). > > > > What compiler are you using exactly ? > > Please try : > > diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c > index 69e4463a4b1b..48791f372aa2 100644 > --- a/net/core/flow_dissector.c > +++ b/net/core/flow_dissector.c > @@ -551,6 +551,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb, > > key_control->thoff = (u16)nhoff; > out: > + barrier(); > key_basic->n_proto = proto; > key_basic->ip_proto = ip_proto; Okay so things are starting to make sense for what I was seeing. I think key_control and key_basic are actually the same pointer.  What has been happening is that storing the network proto is completely overwriting the network header offset with the value of 8. Now to just figure out why. - Alex