netdev - Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard 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] [day] [month] [year] [list]

Message-Id: <20161013.115708.2077879944453283228.davem@davemloft.net>
Date:   Thu, 13 Oct 2016 11:57:08 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     dledford@...hat.com
Cc:     pabeni@...hat.com, linux-rdma@...r.kernel.org,
        sean.hefty@...el.com, hal.rosenstock@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH] IB/ipoib: move back the IB LL address into the hard
 header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard
 header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard
 header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard
 header

From: Doug Ledford <dledford@...hat.com>
Date: Thu, 13 Oct 2016 11:20:59 -0400

> We *had* a safe way to do that.  It got broken.  What about increasing
> the size of skb->cb?  Or adding a skb->dgid that is a
> u8[INFINIBAND_ALEN]?  Or a more generic skb->dest_ll_addr that is sized
> to hold the dest address for any link layer?

I understand the situation, and I also believe that making sk_buff any
huger than it already is happens to be a non-starter.

>> Pushing metadata before the head of the SKB data pointer is illegal,
>> as the layers in between might want to push protocol headers,
> 
> That's a total non-issue for us.  There are no headers that protocols
> can add before ours.

Ok, if that's the case, and based upon Paolo's response to me it appears
to be, I guess this is OK for now.

Paolo please resubmit your patch, thanks.