Am Dienstag, den 18.06.2019, 11:29 -0400 schrieb Alan Stern: > On Tue, 18 Jun 2019, Oliver Neukum wrote: > > > Hi, > > > > looking at those deadlocks it looks to me like UAS can > > deadlock on itself. What do you think? > > > > Regards > > Oliver > > > > From 2d497f662e6c03fe9e0a75e05b64d52514e890b3 Mon Sep 17 00:00:00 2001 > > From: Oliver Neukum <oneukum@xxxxxxxx> > > Date: Tue, 18 Jun 2019 15:03:56 +0200 > > Subject: [PATCH] UAS: fix deadlock in error handling and PM flushing work > > > > A SCSI error handler and block runtime PM must not allocate > > memory with GFP_KERNEL. Furthermore they must not wait for > > tasks allocating memory with GFP_KERNEL. > > That means that they cannot share a workqueue with arbitrary tasks. > > > > Fix this for UAS using a private workqueue. > > I'm not so sure that one long-running task in a workqueue will block > other tasks. Workqueues have variable numbers of threads, added and > removed on demand. (On the other hand, when new threads need to be > added the workqueue manager probably uses GFP_KERNEL.) Do we have a guarantee it will reschedule already scheduled works? The deadlock would be something like uas_pre_reset() -> uas_wait_for_pending_cmnds() -> flush_work(&devinfo->work) -> kmalloc() -> DEADLOCK You can also make this chain with uas_suspend() > Even if you disagree, perhaps we should have a global workqueue with a > permanently set noio flag. It could be shared among multiple drivers > such as uas and the hub driver for purposes like this. (In fact, the > hub driver already has its own dedicated workqueue.) That is a good idea. But does UAS need WQ_MEM_RECLAIM? Regards Oliver
