On Thu, Jan 29, 2026 at 02:32:44PM +0800, Kevin Hao wrote:

On Tue, Jan 27, 2026 at 07:08:36PM -0800, Jakub Kicinski wrote:

quoted

On Tue, 27 Jan 2026 16:02:07 +0800 Kevin Hao wrote:

quoted

To resolve this issue, we opt to execute the actual processing within
a work queue, following the approach used by the icssg-prueth driver.

Code looks good now, but why are you creating a workqueue for this one
work? Can't you use the system wq and just cancel it sync where you had
the wq destroy?

This implementation was adapted from the icssg-prueth driver. After reviewing
the git history, I found no explicit rationale for using a dedicated workqueue.
In my opinion, if we were to use the system wq and rely on cancel_work_sync()
before unregister_netdev(), a race condition could arise between these two calls.
Specifically, cpsw_ndo_set_rx_mode_work() might be scheduled during this interval
and run after the net device is unregistered, leading to a use-after-free bug.

We can use disable_work_sync() instead of cancel_work_sync() to avoid potential
use-after-free issues. I will send a v4 patch to remove this dedicated workqueue.

Thanks,
Kevin