Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200718091732.8761-1-srirakr2@cisco.com> <CA+FuTSdfvctFD3AVMHzQV9efQERcKVE1TcYVD_T84eSgq9x4OA@mail.gmail.com>
 <CY4PR1101MB21013DCD55B754E29AF4A838907B0@CY4PR1101MB2101.namprd11.prod.outlook.com>
In-Reply-To: <CY4PR1101MB21013DCD55B754E29AF4A838907B0@CY4PR1101MB2101.namprd11.prod.outlook.com>
From:   Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date:   Mon, 20 Jul 2020 09:52:27 -0400
Message-ID: <CAF=yD-+gCkPVkXwcH6KiKYGV77TvpZiDo=3YyXeuGFk=TR2dcw@mail.gmail.com>
Subject: Re: [PATCH v2] AF_PACKET doesnt strip VLAN information
To:     "Sriram Krishnan (srirakr2)" <srirakr2@cisco.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        "xe-linux-external(mailer list)" <xe-linux-external@cisco.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Network Development <netdev@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        "Malcolm Bumgardner (mbumgard)" <mbumgard@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jul 20, 2020 at 12:27 AM Sriram Krishnan (srirakr2)
<srirakr2@cisco.com> wrote:
>
> +Stephen Hemminger
>
> Hi Willem,
> Thanks for looking into the code, I understand that this is more of a gen=
eric problem wherein many of the filtering functions assume the vlan tag to=
 be in the skb rather than in the packet. Hence we moved the fix from the d=
river to the common AF packet that our solution uses.
>
> I recall from the v1 of the patch you had mentioned other common areas wh=
ere this fix might be relevant (such as tap/tun), but I'm afraid I cant com=
prehensively test those patches out. Please let me know your thoughts

Please use plain text to respond. HTML replies do not reach the list.

Can you be more precise in which other code besides the hyper-v driver
is affected? Do you have an example?

This is a resubmit of the original patch. My previous
questions/concerns remain valid:

- if the function can now fail, all callers must be updated to detect
and handle that

- any solution should probably address all inputs into the tx path:
packet sockets, tuntap, virtio-net

- this only addresses packet sockets with ETH_P_ALL/ETH_P_NONE. Not
sockets that set ETH_P_8021Q

- which code in the transmit stack requires the tag to be in the skb,
and does this problem after this patch still persist for Q-in-Q?