via-rhine: fix VLAN receive handling error in 4.2.x

via-rhine: fix VLAN receive handling error in 4.2.x

[Andrej]

Hi,


via-rhine driver in 4.2.x kernels doesn’t correctly parse VLAN ID on receive. A bug was introduced in the commit 810f19bcb862f8889b27e0c9d9eceac9593925dd. All 4.2.x kernels are affected. 4.1.x and older kernels are not affected.

During code refactoring, the sequence of calls changed which introduced a regression. Original sequence was:
 1) Read TCI from skb->data
 2) Determine eth protocol using eth_type_trans (which calls skb_pull_inline)
 3) Write TCI to skb->vlan_tci

After the change, the sequence is:
 1) Determine protocol using eth_type_trans (which calls skb_pull_inline)
 2) Read TCI from skb->data
 3) Write TCI to skb->vlan_tci

Because eth_type_trans consumes ethernet header worth of bytes, a call to read TCI from packet no longer works as expected as it’s reading from invalid offset.

Choosing between changing rhine_get_vlan_tci(), which retrieves TCI from skb->data, or moving eth_type_trans() invocation after rhine_rx_vlan_tag(), I chose the latter.


Andrej.


--- linux-4.2.2.orig/drivers/net/ethernet/via/via-rhine.c       2015-10-03 15:46:59.817000000 +0200
+++ linux-4.2.2/drivers/net/ethernet/via/via-rhine.c    2015-10-03 18:53:51.799000000 +0200
@@ -2134,10 +2134,11 @@
 			}
 
 			skb_put(skb, pkt_len);
-			skb->protocol = eth_type_trans(skb, dev);
 
 			rhine_rx_vlan_tag(skb, desc, data_size);
 
+			skb->protocol = eth_type_trans(skb, dev);
+
 			netif_receive_skb(skb);
 
 			u64_stats_update_begin(&rp->rx_stats.syncp);

Re: via-rhine: fix VLAN receive handling error in 4.2.x

[Francois Romieu]

Andrej <andrej@ota.si> :
[...]
> Choosing between changing rhine_get_vlan_tci(), which retrieves TCI from
> skb->data, or moving eth_type_trans() invocation after rhine_rx_vlan_tag(),
> I chose the latter.

Can you send a patch with a proper Signed-off-by and a single line
'Fixes: 810f19bcb862 ("via-rhine: add consistent memory barrier in vlan
receive code.")' or do you want me to do that ?

The patch ought to be based against davem's net but it wouldn't make
any noticeable difference.

-- 
Ueimor

[PATCH] via-rhine: fix VLAN receive handling error in 4.2.x

[Andrej Ota]

Fixes commit 810f19bcb862 ("via-rhine: add consistent memory barrier in
vlan receive code.") which broke VLAN tag parsing on receive.

Because eth_type_trans() consumes ethernet header worth of bytes, a call
to read TCI from packet using rhine_rx_vlan_tag() no longer works as it's
reading from an invalid offset.

Tested to be working on PCEngines Alix board.

Fixes: 810f19bcb862 ("via-rhine: add consistent memory barrier in vlan receive code.")
Signed-off-by: Andrej Ota <andrej@ota.si>
---
 drivers/net/ethernet/via/via-rhine.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
index a832637..2b7550c 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -2134,10 +2134,11 @@ static int rhine_rx(struct net_device *dev, int limit)
 			}
 
 			skb_put(skb, pkt_len);
-			skb->protocol = eth_type_trans(skb, dev);
 
 			rhine_rx_vlan_tag(skb, desc, data_size);
 
+			skb->protocol = eth_type_trans(skb, dev);
+
 			netif_receive_skb(skb);
 
 			u64_stats_update_begin(&rp->rx_stats.syncp);
-- 
2.4.3

Re: [PATCH] via-rhine: fix VLAN receive handling error in 4.2.x

[Francois Romieu]

Andrej Ota <andrej@ota.si> :
> Fixes commit 810f19bcb862 ("via-rhine: add consistent memory barrier in
> vlan receive code.") which broke VLAN tag parsing on receive.
> 
> Because eth_type_trans() consumes ethernet header worth of bytes, a call
> to read TCI from packet using rhine_rx_vlan_tag() no longer works as it's
> reading from an invalid offset.
> 
> Tested to be working on PCEngines Alix board.
> 
> Fixes: 810f19bcb862 ("via-rhine: add consistent memory barrier in vlan receive code.")
> Signed-off-by: Andrej Ota <andrej@ota.si>

Minor nits:
- Ethernet driver patches should usually be sent to netdev@vger.kernel.org.
  Their state is thus tracked at
  http://patchwork.ozlabs.org/project/netdev/list/

- The more specific about the target branch, the better:
  [PATCH net 1/1] via-rhine: blah
  -> patch against davem's bugfixes branch
  [PATCH net-next 19/73] foo: more balh
  -> patch against davem's dev branch

- davem will take care of -stable propagation

-- 
Ueimor