All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevic@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net] net: Account for all vlan headers in skb_mac_gso_segment
Date: Wed, 26 Mar 2014 12:20:50 -0400	[thread overview]
Message-ID: <5332FE62.504@redhat.com> (raw)
In-Reply-To: <1395850483.12610.213.camel@edumazet-glaptop2.roam.corp.google.com>

On 03/26/2014 12:14 PM, Eric Dumazet wrote:
> On Wed, 2014-03-26 at 11:51 -0400, Vlad Yasevich wrote:
>> skb_network_protocol() already accounts for multiple vlan
>> headers that may be present in the skb.  However, skb_mac_gso_segment()
>> doesn't know anything about it and assumes that skb->mac_len
>> is set correctly to skip all mac headers.  That may not
>> always be the case.  If we are simply forwarding the packet (via
>> bridge or macvtap), all vlan headers may not be accounted for.
>>
>> A simple solution is to allow skb_network_protocol to return
>> the vlan depth it has calculated.  This way skb_mac_gso_segment
>> will correctly skip all mac headers.
>>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>> ---
>>  include/linux/netdevice.h |  2 +-
>>  net/core/dev.c            | 12 ++++++++----
>>  net/core/skbuff.c         |  2 +-
>>  3 files changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index d855794..18b8c1b 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -3015,7 +3015,7 @@ struct sk_buff *skb_gso_segment(struct sk_buff *skb, netdev_features_t features)
>>  {
>>  	return __skb_gso_segment(skb, features, true);
>>  }
>> -__be16 skb_network_protocol(struct sk_buff *skb);
>> +__be16 skb_network_protocol(struct sk_buff *skb, int *depth);
>>  
>>  static inline bool can_checksum_protocol(netdev_features_t features,
>>  					 __be16 protocol)
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index a98f7fa..49c41e6 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2287,7 +2287,7 @@ out:
>>  }
>>  EXPORT_SYMBOL(skb_checksum_help);
>>  
>> -__be16 skb_network_protocol(struct sk_buff *skb)
>> +__be16 skb_network_protocol(struct sk_buff *skb, int *depth)
>>  {
>>  	__be16 type = skb->protocol;
>>  	int vlan_depth = ETH_HLEN;
>> @@ -2314,6 +2314,9 @@ __be16 skb_network_protocol(struct sk_buff *skb)
>>  		vlan_depth += VLAN_HLEN;
>>  	}
>>  
>> +	if (depth)
>> +		*depth = vlan_depth;
> 
> expensive test, just always pass a non NULL pointer, to a dummy stack
> variable.
> 
>> +
>>  	return type;
>>  }
>>  
>> @@ -2327,12 +2330,13 @@ struct sk_buff *skb_mac_gso_segment(struct sk_buff *skb,
>>  {
>>  	struct sk_buff *segs = ERR_PTR(-EPROTONOSUPPORT);
>>  	struct packet_offload *ptype;
>> -	__be16 type = skb_network_protocol(skb);
>> +	int vlan_depth = 0;
> vlan_depth = ETH_HLEN;

safer to make it skb->mac_len.

> 
>> +	__be16 type = skb_network_protocol(skb, &vlan_depth);
>>  
>>  	if (unlikely(!type))
>>  		return ERR_PTR(-EINVAL);
>>  
>> -	__skb_pull(skb, skb->mac_len);
>> +	__skb_pull(skb, vlan_depth > skb->mac_len ? vlan_depth : skb->mac_len);
> 
> Please remove this test

Couldn't mac_len be larger that ETH_HLEN already?

> 
> 	__skb_pull(skb, vlan_depth);
> 

The other variant of this patch that I tested was simply adjusting
skb->mac_len directly in skb_network_protocol().  I didn't encounter any
issues with it, but didn't like the potential side-effects for GSO
and thus didn't send it.  Can you see any issue with that approach?

Thanks
-vlad

  reply	other threads:[~2014-03-26 16:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26 15:51 [PATCH net] net: Account for all vlan headers in skb_mac_gso_segment Vlad Yasevich
2014-03-26 16:14 ` Eric Dumazet
2014-03-26 16:20   ` Vlad Yasevich [this message]
2014-03-31 21:22 ` Neil Jerram
2014-03-31 21:37   ` Vlad Yasevich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5332FE62.504@redhat.com \
    --to=vyasevic@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.