Re: [PATCH v3 net-next 5/6] net: usb: pegasus: Move long delayed work on system_dfl_long_wq

[Alan Stern]

On Tue, Aug 25, 2026 at 05:18:12PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-07-22 10:29:50 [+0200], Oliver Neukum wrote:
> > On 20.07.26 12:08, Marco Crivellari wrote:
> > Hi,
> Hi Oliver,
> 
> > > Since the workqueue work doesn't rely on per-cpu variables, there is no
> > > obvious reason that justify the use of a per-cpu workqueue. So change
> > > system_long_wq with system_dfl_long_wq so that the work may benefit from
> > > scheduler task placement.
> > 
> > these changes are problematic, although they look like a good cleanup
> > in first place. But the test you are using to determine whether USB
> > devices need their own work queue is incomplete because you are not
> > considering the reason they allocate their own work queues.
> 
> This driver does not using its own workqueue.
> 
> > These drivers have their own work queues because they are part of the block layer.
> > USB devices can share a device with a block device (storage & UAS) and
> > USB devices have common, per device operations, in particular reset
> > and runtime power management and disconnect handling. Because these operations
> > can be necessary to complete block IO neither they nor anything
> > they depend on can use IO to allocate memory. That is they need to
> > perform any memory allocation with GFP_NOIO or GFP_ATOMIC.
> 
> This is a networking driver. It has nothing to do with storage and UAS.
> It uses USB, yes.

Ah, but a composite USB device can have both a networking interface and 
a mass-storage interface.

Suppose you have such a device, and suppose the disk attached to its 
mass-storage interface contains a swap partition.  Now suppose the 
device is being reset, and as part of the preparation for that reset the 
networking driver needs to flush its workqueue.  This means waiting 
until the work routines that are already running have completed.

Since it's a general-purpose workqueue, you don't know what those work 
routines are going to do.  One of them might try to allocate memory 
using GFP_KERNEL.  Suppose that in order to satisfy the memory request, 
the kernel decides it needs to write some pages to the swap partition on 
the USB mass-storage interface.  But the mass-storage driver is stuck; 
it can't do anything until the device reset finishes.  Deadlock.

That's why USB drivers have to use their own workqueues.

Alan Stern