[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPrAcgMhphs1U88_POpxAeAp0KzNCH6-xuvNiSBa5dn7ceSU4w@mail.gmail.com>
Date: Wed, 24 Sep 2025 15:55:07 +0530
From: viswanath <viswanathiyyappan@...il.com>
To: Michal Pecio <michal.pecio@...il.com>
Cc: andrew@...n.ch, andrew+netdev@...n.ch, davem@...emloft.net,
david.hunter.linux@...il.com, edumazet@...gle.com, kuba@...nel.org,
linux-kernel-mentees@...ts.linux.dev, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, netdev@...r.kernel.org, pabeni@...hat.com,
petkan@...leusys.com, skhan@...uxfoundation.org,
syzbot+78cae3f37c62ad092caa@...kaller.appspotmail.com
Subject: Re: [PATCH net v2] net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast
On Wed, 24 Sept 2025 at 15:06, Michal Pecio <michal.pecio@...il.com> wrote:
>
> I think yes, usually in USB-speak "completion" is when the URB is
> finished for any reason, including error or unlink/cancellation.
> "Free" could suggest usb_free_urb().
>
> But I see your point. Maybe "finish execution" is less ambiguous?
>
I will use completion if it's the standard terminology
> I think it's an irrelevant detail which CPU executed which function.
> It could all happen sequentially on a single core and it's still the
> same bug.
>
> In fact, I just reproduced it with all CPUs offlined except one.
My bad, I see it now. I keep forgetting the actual urb execution
is asynchronous
Thanks
Viswanath
Powered by blists - more mailing lists