On Mon, 20 Jul 2020 09:52:27 -0400 Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote:
> On Mon, Jul 20, 2020 at 12:27 AM Sriram Krishnan (srirakr2) > <srira...@cisco.com> wrote: > > > > +Stephen Hemminger > > > > Hi Willem, > > Thanks for looking into the code, I understand that this is more of a > > generic 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 > > driver to the common AF packet that our solution uses. > > > > I recall from the v1 of the patch you had mentioned other common areas > > where this fix might be relevant (such as tap/tun), but I'm afraid I cant > > comprehensively 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? It matters because the problem is generic, not just to the netvsc driver. For example, BPF programs and netfilter rules will see different packets when send is through AF_PACKET than they would see for sends from the kernel stack. Presenting uniform data to the lower layers makes sense.
