lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Aug 2018 19:27:55 +0800
From:   Jisheng Zhang <Jisheng.Zhang@...aptics.com>
To:     Marek BehĂșn <marek.behun@....cz>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     linux-arm-kernel@...ts.infradead.org, netdev@...r.kernel.org,
        Gregory CLEMENT <gregory.clement@...tlin.com>,
        Tomas Hlavacek <tomas.hlavacek@....cz>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720

Hi,

On Thu, 9 Aug 2018 12:40:41 +0800 Jisheng Zhang wrote:

> + more people
> 
> On Wed,  8 Aug 2018 17:27:05 +0200 Marek BehĂșn wrote:
> 
> > For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the
> > networking driver behaves weirdly when using napi_gro_receive.
> > 
> > For example downloading a big file from a local network (low ping) is
> > fast, but when downloading from a remote server (higher ping), the
> > download speed is at first high but drops rapidly to almost nothing or
> > absolutely nothing.  
> 
> We also met this issue on some berlin platforms. I tried to fix the bug,
> but no clue so far.
> 
> > 
> > This is fixed when using netif_receive_skb instead of napi_gro_receive.  
> 
> This is a workaround. The good news is this workaround also fixes the issue
> we saw on berlin.
> 
> > 
> > Signed-off-by: Marek Behun <marek.behun@....cz>
> > Cc: Russell King - ARM Linux <linux@...linux.org.uk>
> > Cc: netdev@...r.kernel.org
> > 
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> > index 0ad2f3f7da85..27f3017d94c5 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -1959,7 +1959,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
> >  
> >  			skb->protocol = eth_type_trans(skb, dev);
> >  			mvneta_rx_csum(pp, rx_status, skb);
> > -			napi_gro_receive(&port->napi, skb);
> > +			if (pp->neta_armada3700)
> > +				netif_receive_skb(skb);
> > +			else
> > +				napi_gro_receive(&port->napi, skb);

I think I found the root cause, if neta_armada3700 is true, the port got from
this_cpu_ptr(pp->ports) is invalid, this is bug... I'll cook a patch for this

Thanks

> >  
> >  			rcvd_pkts++;
> >  			rcvd_bytes += rx_bytes;
> > @@ -2001,7 +2004,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
> >  
> >  		mvneta_rx_csum(pp, rx_status, skb);
> >  
> > -		napi_gro_receive(&port->napi, skb);
> > +		if (pp->neta_armada3700)
> > +			netif_receive_skb(skb);
> > +		else
> > +			napi_gro_receive(&port->napi, skb);
> >  	}
> >  
> >  	if (rcvd_pkts) {  
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ