All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zahari Doychev <zahari.doychev@linux.com>
To: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Cc: jiri@resnulli.us, nikolay@cumulusnetworks.com,
	netdev@vger.kernel.org, roopa@cumulusnetworks.com,
	bridge@lists.linux-foundation.org, jhs@mojatatu.com,
	xiyou.wangcong@gmail.com, johannes@sipsolutions.net
Subject: Re: [Bridge] [PATCH 1/2] net: bridge: fix tc added QinQ forwarding
Date: Thu, 17 Jan 2019 09:17:07 +0100	[thread overview]
Message-ID: <20190117081707.GA13853@riot> (raw)
In-Reply-To: <7dee9e67-bad5-84eb-9ff1-fa0d0aef8be0@lab.ntt.co.jp>

On Tue, Jan 15, 2019 at 03:11:28PM +0900, Toshiaki Makita wrote:
> On 2019/01/13 22:59, Zahari Doychev wrote:
> > Use the skb->mac_len instead of using the ETH_HLEN when pushing the skb
> > data pointer. This fixes sending incorrect packets when more than one
> > vlan tags are pushed by tc-vlan and the mac header length is bigger than
> > ETH_HLEN. In this way the vlan tagged contained in the skb is inserted at
> > right offset in the packet payload before sending the packet.
> > 
> > Signed-off-by: Zahari Doychev <zahari.doychev@linux.com>
> > ---
> >  net/bridge/br_forward.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
> > index 5372e2042adf..55f928043f77 100644
> > --- a/net/bridge/br_forward.c
> > +++ b/net/bridge/br_forward.c
> > @@ -39,7 +39,7 @@ int br_dev_queue_push_xmit(struct net *net, struct sock *sk, struct sk_buff *skb
> >  	if (!is_skb_forwardable(skb->dev, skb))
> >  		goto drop;
> >  
> > -	skb_push(skb, ETH_HLEN);
> > +	skb_push(skb, skb->mac_len);
> >  	br_drop_fake_rtable(skb);
> >  
> >  	if (skb->ip_summed == CHECKSUM_PARTIAL &&
> > 
> 
> I guess you mean skb->data points to mac_header + ETH_HLEN + VLAN_HLEN
> when bridge receives skbs in br_handle_frame()?

yes, this is what I see.

> If so, the behavior of act_vlan is odd. Normal double tagged skbs from
> hardware devices should have skb->data pointing to mac_header + ETH_HLEN
> because they just call eth_type_trans() before entering
> netif_receive_skb()...
> I think act_vlan needs some fix.

The act_valn is using the skb_vlan_push(...) to add the vlan tags and in this
way increasing the skb->data and mac_len. So I think I can add a fix there to
set the skb->data to point to mac_header + ETH_HLEN when more tags are added.

Thanks
Zahari

> 
> -- 
> Toshiaki Makita
> 

WARNING: multiple messages have this Message-ID (diff)
From: Zahari Doychev <zahari.doychev@linux.com>
To: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
	nikolay@cumulusnetworks.com, roopa@cumulusnetworks.com,
	johannes@sipsolutions.net, jhs@mojatatu.com, jiri@resnulli.us,
	xiyou.wangcong@gmail.com
Subject: Re: [Bridge] [PATCH 1/2] net: bridge: fix tc added QinQ forwarding
Date: Thu, 17 Jan 2019 09:17:07 +0100	[thread overview]
Message-ID: <20190117081707.GA13853@riot> (raw)
In-Reply-To: <7dee9e67-bad5-84eb-9ff1-fa0d0aef8be0@lab.ntt.co.jp>

On Tue, Jan 15, 2019 at 03:11:28PM +0900, Toshiaki Makita wrote:
> On 2019/01/13 22:59, Zahari Doychev wrote:
> > Use the skb->mac_len instead of using the ETH_HLEN when pushing the skb
> > data pointer. This fixes sending incorrect packets when more than one
> > vlan tags are pushed by tc-vlan and the mac header length is bigger than
> > ETH_HLEN. In this way the vlan tagged contained in the skb is inserted at
> > right offset in the packet payload before sending the packet.
> > 
> > Signed-off-by: Zahari Doychev <zahari.doychev@linux.com>
> > ---
> >  net/bridge/br_forward.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
> > index 5372e2042adf..55f928043f77 100644
> > --- a/net/bridge/br_forward.c
> > +++ b/net/bridge/br_forward.c
> > @@ -39,7 +39,7 @@ int br_dev_queue_push_xmit(struct net *net, struct sock *sk, struct sk_buff *skb
> >  	if (!is_skb_forwardable(skb->dev, skb))
> >  		goto drop;
> >  
> > -	skb_push(skb, ETH_HLEN);
> > +	skb_push(skb, skb->mac_len);
> >  	br_drop_fake_rtable(skb);
> >  
> >  	if (skb->ip_summed == CHECKSUM_PARTIAL &&
> > 
> 
> I guess you mean skb->data points to mac_header + ETH_HLEN + VLAN_HLEN
> when bridge receives skbs in br_handle_frame()?

yes, this is what I see.

> If so, the behavior of act_vlan is odd. Normal double tagged skbs from
> hardware devices should have skb->data pointing to mac_header + ETH_HLEN
> because they just call eth_type_trans() before entering
> netif_receive_skb()...
> I think act_vlan needs some fix.

The act_valn is using the skb_vlan_push(...) to add the vlan tags and in this
way increasing the skb->data and mac_len. So I think I can add a fix there to
set the skb->data to point to mac_header + ETH_HLEN when more tags are added.

Thanks
Zahari

> 
> -- 
> Toshiaki Makita
> 

  reply	other threads:[~2019-01-17  8:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-13 13:59 [Bridge] [PATCH 0/2] net: bridge: fix tc added QinQ forwarding Zahari Doychev
2019-01-13 13:59 ` Zahari Doychev
2019-01-13 13:59 ` [Bridge] [PATCH 1/2] " Zahari Doychev
2019-01-13 13:59   ` Zahari Doychev
2019-01-15  6:11   ` [Bridge] " Toshiaki Makita
2019-01-17  8:17     ` Zahari Doychev [this message]
2019-01-17  8:17       ` Zahari Doychev
2019-01-17  8:57       ` Toshiaki Makita
2019-01-17  8:57         ` Toshiaki Makita
2019-01-17 19:19         ` Cong Wang
2019-01-17 19:19           ` Cong Wang
2019-01-18  2:29           ` Toshiaki Makita
2019-01-18  2:29             ` Toshiaki Makita
2019-01-21 21:11             ` Zahari Doychev
2019-01-22  8:45               ` Toshiaki Makita
2019-01-13 13:59 ` [Bridge] [PATCH 2/2] net: bridge: fix tc added vlan insert as payload Zahari Doychev
2019-01-13 13:59   ` Zahari Doychev
2019-01-14 11:46 ` [Bridge] [PATCH 0/2] net: bridge: fix tc added QinQ forwarding Nikolay Aleksandrov
2019-01-14 11:46   ` Nikolay Aleksandrov
2019-01-14 19:47   ` [Bridge] " Zahari Doychev
2019-01-14 19:47     ` Zahari Doychev

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=20190117081707.GA13853@riot \
    --to=zahari.doychev@linux.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=johannes@sipsolutions.net \
    --cc=makita.toshiaki@lab.ntt.co.jp \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=roopa@cumulusnetworks.com \
    --cc=xiyou.wangcong@gmail.com \
    /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.