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]

Message-ID: <CAG4TOxOBCbEEOtP62ZM1R3-6umebdbJFkK0bnjphLCZOgHzt1g@mail.gmail.com>
Date:	Mon, 6 Feb 2012 09:23:58 -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 8:58 AM, David Miller <davem@...emloft.net> wrote:
>
> So if IPoIB path resolution was properly integrated into the neighbour
> cache state machine, instead of being implemented awkwardly in the
> device transmit path, this crap wouldn't be necessary right?
>
> So here we have yet another incredibly painful side effect of how
> IPoIB path resolution works.
>
> Roland, I want you to seriously consider a way, any way, to get rid of
> how IPoIB does path resolution.  It must be fully integrated into the
> neighbour layer, the neighbour layer must be knowledgable about how
> path resolution is a necessary step for a neighbour entry to enter the
> valid state, and I want all of this awkward neighbour handling code
> removed from the transmit path of IPoIB.
>
> And finally it must not lie about it's hardware header length.

I would love to clean this up.  But I don't know how to do it.

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.

However this LL address is not actually what we need to send
a packet -- we need to take the GID of our destination and send
a query to the subnet manager to resolve it to a path.  And this
query really is an RPC to a remote entity somewhere else on
the network, so we have to do it asynchronously etc.

Now the part I don't know how to handle is when the network
stack gives us a LL address to send an ARP or something to
but the skb has no dst attached.  Suppose I don't have a path
for that LL address when I get that skb with no dst into my
.hard_header method.  Where do I stick the LL addr to keep
around until the packet shows up in the xmit function?

 - 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