netdev - Re: [PATCH net-next V2] gro: introduce gro_mac_header

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Feb 2012 11:23:21 -0800
From:	Roland Dreier <roland@...nel.org>
To:	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, ogerlitz@...lanox.com,
	sean.hefty@...el.com, herbert@...dor.hengli.com.au,
	linux-rdma@...r.kernel.org, shlomop@...lanox.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next V2] gro: introduce gro_mac_header_len

On Mon, Feb 6, 2012 at 11:12 AM, David Miller <davem@...emloft.net> wrote:
>> IMHO the problem is in the IPoIB RFC: (4391) which makes
>> a distinction between an "encapsulation header" and the "link
>> layer address".  The LL address is what we put into ARP and
>> ND packets, and so I think we are forced into exposing that
>> to the network stack as our hardware address.
>
> An address is not a hardware MAC header, we're only talking
> about the length of the latter.
>
> If the addressing is such that you need to put the GID
> into the ARP/NDISC packets, and that's different from what
> ends up in the final encapsulation header, I really don't
> see what the problem is specificially with respect to the
> MAC header size.

Dave, please look at my whole email.  The problem is that
the LL addr is not what we need to send packets but it's all
we get in our .hard_header method.  So for eg unicast ARP
packets without a dst we have nowhere to stash what we
actually will need in our xmit method.

(The same problem for unicast ARPs applies to multicast
sends too).

Does the netdev driver own skb->cb between hard_header
and start_xmit?  If so we could use that instead of stealing
some header space, and that would at least let us not lie
about hard_header_len.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html