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]
Message-ID: <32c71d3245127b4aa02b8abd75edcb8f5767e966.camel@redhat.com>
Date: Tue, 05 Sep 2023 12:10:57 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Hayes Wang <hayeswang@...ltek.com>, kuba@...nel.org, davem@...emloft.net
Cc: netdev@...r.kernel.org, nic_swsd@...ltek.com,
 linux-kernel@...r.kernel.org,  linux-usb@...r.kernel.org
Subject: Re: [PATCH net] r8152: avoid the driver drops a lot of packets

Hello,

On Mon, 2023-09-04 at 20:17 +0800, Hayes Wang wrote:
> Stop submitting rx, if the driver queue more than 256 packets.
> 
> If the hardware is more fast than the software, the driver would start
> queuing the packets. And, the driver starts dropping the packets, if it
> queues more than 1000 packets.
> 
> Increase the weight of NAPI could improve the situation. However, the
> weight has been changed to 64, so we have to stop submitting rx when the
> driver queues too many packets. Then,the device may send the pause frame
> to slow down the receiving, when the FIFO of the device is full.
> 
> Fixes: cf74eb5a5bc8 ("eth: r8152: try to use a normal budget")
> Signed-off-by: Hayes Wang <hayeswang@...ltek.com>
> ---
>  drivers/net/usb/r8152.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 332c853ca99b..b5ed55938b1c 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -2484,10 +2484,6 @@ static int rx_bottom(struct r8152 *tp, int budget)
>  			unsigned int pkt_len, rx_frag_head_sz;
>  			struct sk_buff *skb;
>  
> -			/* limit the skb numbers for rx_queue */
> -			if (unlikely(skb_queue_len(&tp->rx_queue) >= 1000))
> -				break;
> -

Dropping this check looks dangerous to me. What if pause frames are
disabled on the other end or dropped? It looks like this would cause
unlimited memory consumption?!?

If this limit is not supposed to be reached under normal conditions,
perhaps is worthy changing it into a WARN_ON_ONCE()?

Thanks!

Paolo


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ