netdev - RE: NAPI on USB network drivers

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: <0835B3720019904CB8F7AA43166CEEB201A13775@RTITMBSV06.realtek.com.tw>
Date:   Thu, 26 Jan 2017 01:43:23 +0000
From:   Hayes Wang <hayeswang@...ltek.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
CC:     Oliver Neukum <oneukum@...e.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: RE: NAPI on USB network drivers

Eric Dumazet [mailto:eric.dumazet@...il.com]
> Sent: Wednesday, January 25, 2017 10:13 PM
[...]
> You also could use napi_complete_done() instead of napi_complete(), as
> it allows users to tune the performance vs latency for GRO.
> 
> Looking at this driver, I do not see any limitation on the number of
> skbs that can be pushed into tp->rx_queue.
> 
> I wonder if this queue can end up consuming all memory of a host under
> stress.
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index
> e1466b4d2b6c727148a884672bbd9593bf04b3ac..221df4a931b5c1073f1922d0fa0b
> bff158c73b7d 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1840,7 +1840,10 @@ static int rx_bottom(struct r8152 *tp, int budget)
>  				stats->rx_packets++;
>  				stats->rx_bytes += pkt_len;
>  			} else {
> -				__skb_queue_tail(&tp->rx_queue, skb);
> +				if (unlikely(skb_queue_len(&tp->rx_queue) >= 1000))
> +					kfree_skb(skb);
> +				else
> +					__skb_queue_tail(&tp->rx_queue, skb);
>  			}
> 
>  find_next_rx:

Thanks for your suggestion. I would submit it later.

Best Regards,
Hayes