Linux USB
 help / color / mirror / Atom feed
From: "Ömer Mete Kaya" <omermetekaya0@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()
Date: Fri, 9 Oct 2026 18:48:50 +0300	[thread overview]
Message-ID: <cc9f0c2d-7f41-477b-a1dc-9d5a7146af71@gmail.com> (raw)
In-Reply-To: <sashiko-outbox-164620@kernel.org>



On 10/9/26 01:03, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] net: out-of-order packet delivery during RX resume
> --
> 
> commit 7148b0b2b0b945f31b2120d7f4cbc269acf91635
> Author: Ömer Mete Kaya <omermetekaya0@gmail.com>
> 
> usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()
> 
> This commit addresses a race condition in usbnet_skb_return() by protecting
> the EVENT_RX_PAUSED flag check and enqueue operations with a double-check
> pattern under the rxq_pause lock. It also protects the clear_bit() operation
> in usbnet_resume_rx() under the same lock.
> 
>> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
>> index a19ecf718f36a..d1ec3ba1e10e6 100644
>> --- a/drivers/net/usb/usbnet.c
>> +++ b/drivers/net/usb/usbnet.c
> [ ... ]
>> @@ -700,15 +705,16 @@ void usbnet_resume_rx(struct usbnet *dev)
>>  	int num = 0;
>>  
>>  	local_bh_disable();
>> +	spin_lock(&dev->rxq_pause.lock);
>>  	clear_bit(EVENT_RX_PAUSED, &dev->flags);
>> -
>> +	spin_unlock(&dev->rxq_pause.lock);
> 
> [Severity: Medium]
> If a new packet arrives concurrently on another CPU via usbnet_skb_return(),
> could it observe EVENT_RX_PAUSED as false here?
> 
> If so, it would bypass the pause queue and immediately deliver the new SKB
> to the network stack via netif_rx().
> 
>>  	while ((skb = skb_dequeue(&dev->rxq_pause)) != NULL) {
>>  		usbnet_skb_return(dev, skb);
>>  		num++;
>>  	}
> 
> This seems like it would cause the newly arrived packet to be delivered before
> the older packets in the rxq_pause queue are fully drained by this while loop,
> leading to out-of-order delivery which can degrade TCP performance.
> 
The out-of-order delivery window between clear_bit() and the drain loop
is a pre-existing issue in the original code, not introduced by this
patch.

      reply	other threads:[~2026-10-09 15:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 22:01 [PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return() Ömer Mete Kaya
2026-10-07 22:09 ` netdev-bot+sinfo
2026-10-08 15:40   ` Jakub Kicinski
2026-10-08 15:47     ` Ömer Mete Kaya
2026-10-08 18:03       ` Jakub Kicinski
2026-10-08 15:42   ` Ömer Mete Kaya
2026-10-08 22:03 ` sashiko-bot
2026-10-09 15:48   ` Ömer Mete Kaya [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cc9f0c2d-7f41-477b-a1dc-9d5a7146af71@gmail.com \
    --to=omermetekaya0@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox