[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20161003.214235.1262526925870231271.davem@davemloft.net>
Date: Mon, 03 Oct 2016 21:42:35 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: shmulik.ladkani@...il.com
Cc: netdev@...r.kernel.org, jhs@...atatu.com, daniel@...earbox.net,
pshelar@....org, jiri@...lanox.com
Subject: Re: [PATCH v3 net 2/2] net: skbuff: Limit skb_vlan_pop/push() to
expect skb->data at mac header
From: Shmulik Ladkani <shmulik.ladkani@...il.com>
Date: Thu, 29 Sep 2016 12:10:41 +0300
> skb_vlan_pop/push were too generic, trying to support the cases where
> skb->data is at mac header, and cases where skb->data is arbitrarily
> elsewhere.
>
> Supporting an arbitrary skb->data was complex and bogus:
> - It failed to unwind skb->data to its original location post actual
> pop/push.
> (Also, semantic is not well defined for unwinding: If data was into
> the eth header, need to use same offset from start; But if data was
> at network header or beyond, need to adjust the original offset
> according to the push/pull)
> - It mangled the rcsum post actual push/pop, without taking into account
> that the eth bytes might already have been pulled out of the csum.
>
> Most callers (ovs, bpf) already had their skb->data at mac_header upon
> invoking skb_vlan_pop/push.
> Last caller that failed to do so (act_vlan) has been recently fixed.
>
> Therefore, to simplify things, no longer support arbitrary skb->data
> inputs for skb_vlan_pop/push().
>
> skb->data is expected to be exactly at mac_header; WARN otherwise.
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@...il.com>
Applied.
Powered by blists - more mailing lists