On Sat, Feb 28, 2015 at 10:08 PM, David Miller [off-list ref] wrote:

From: Eyal Birger <redacted>
Date: Sat, 28 Feb 2015 21:39:34 +0200

quoted

On Sat, Feb 28, 2015 at 9:21 PM, David Miller [off-list ref] wrote:

quoted

From: Eyal Birger <redacted>
Date: Thu, 26 Feb 2015 21:07:01 +0200

quoted

As part of an effort to move skb->dropcount to skb->cb[], 4 bytes
of additional room are needed in skb->cb[] in packet sockets.

Store the skb original length in skb->dev instead of skb->cb[] for
this purpose.

Signed-off-by: Eyal Birger <redacted>

I'm a little confused, why is this even needed?

packet_skb_cb is 24 bytes by my calculations, which is much
smaller than the cb[] size which is 48 bytes.

Note the BUILD_BUG_ON in packet_rcv().

packet_skb_cb may contain an address as large as MAX_ADDR_LEN (32)
Therefore the required space is sizeof(packet_skb_cb) + MAX_ADDR_LEN - 8
which is 48 bytes before this change.

So let's take a step back.

What link layer we support has 32-byte hardware addresses?

The largest one I've been hinted of is INFINIBAND_ALEN which is 20 bytes.

If the answer is lower than 32, we should use that value instead.

Won't that value become the 'real' MAX_ADDR_LEN in that case?

My concern is that any value I pick based on the existing implementations
would need to be adjusted come a protocol with a larger address length.

Also, I would have to assert the available amount of space at run-time as
the address length is provided by a call to dev_parse_header() instead of
using a build-time assert.

Regards,
Eyal.