linux-kernel - Re: [PATCH] net: usb: Remove disruptive netif_wake_queue in rtl8150_set

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: <83171a57-cb40-4c97-b736-0e62930b9e5c@lunn.ch>
Date: Sat, 20 Sep 2025 19:28:59 +0200
From: Andrew Lunn <andrew@...n.ch>
To: viswanath <viswanathiyyappan@...il.com>
Cc: petkan@...leusys.com, andrew+netdev@...n.ch, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	linux-usb@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, skhan@...uxfoundation.org,
	linux-kernel-mentees@...ts.linux.dev, david.hunter.linux@...il.com,
	syzbot+78cae3f37c62ad092caa@...kaller.appspotmail.com
Subject: Re: [PATCH] net: usb: Remove disruptive netif_wake_queue in
 rtl8150_set_multicast

>     Thanks for pointing that out. I wasn't thinking from that point of view.
> 
>     According to Documentation, rtl8150_set_multicast (the
> ndo_set_rx_mode callback) should
>     rely on the netif_addr_lock spinlock, not the netif_tx_lock
> manipulated by netif
>     stop/start/wake queue functions.
> 
>     However, There is no need to use the netif_addr_lock in the driver
> directly because
>     the core function (dev_set_rx_mode) invoking this function locks
> and unlocks the lock
>     correctly.
> 
>     Synchronization is therefore handled by the core, making it safe
> to remove that lock.
> 
>     From what I have seen, every network driver assumes this for the
> ndo_set_rx_mode callback.
> 
>     I am not sure what the historical context was for using the
> tx_lock as the synchronization
>     mechanism here but it's definitely not valid in the modern networking stack.

Thanks. Please include an explanation in V2. Also, please read:

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

	Andrew