linux-kernel - Re: [PATCH net] r8152: avoid the driver drops a lot of packets

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

On Tue, 2023-09-05 at 10:37 +0000, Hayes Wang wrote:
> Paolo Abeni <pabeni@...hat.com>
> > Sent: Tuesday, September 5, 2023 6:11 PM
> [...]
> > > -                     /* 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?!?
> 
> When the driver stops submitting rx, the driver wouldn't get any packet
> from the device after the previous urbs which have been submitted return.
> That is, skb_queue_len(&tp->rx_queue) wouldn't increase any more until
> the driver starts submitting rx again.
> 
> Now, the driver stops submitting rx when the skb_queue_len more than 256,
> so the check becomes redundant. The skb_queue_len has been limited less
> than 1000.

I'm sorry, I have a very superficial knowledge of the USB layer, but it
looks like that when such condition is reached, in the worst condition
there could be up to urbs in flight. AFAICS each of them carries a 16K
buffer, can be up to 10 standard-mtu packets - or much more small ones.

Setting an upper limits to the rx_queue still looks like a reasonable
safeguard.

> Besides, if the flow control is disabled, the packets may be dropped by
> the hardware when the FIFO of the device is full, after the driver stops
> submitting rx.

If the incoming rate exceeds the H/W processing capacity, packets are
dropped: that is expected and unavoidable.

Possibly exposing the root cause for such drops to user space via
appropriate stats would be useful.

Cheers,

Paolo