On Tue, 28 May 2019, Oliver Neukum wrote: > Am Donnerstag, den 23.05.2019, 10:01 -0400 schrieb Alan Stern: > > On Wed, 22 May 2019, Oliver Neukum wrote: > > > > > On Mi, 2019-05-22 at 10:56 -0400, Alan Stern wrote: > > > > On Wed, 22 May 2019, Oliver Neukum wrote: > > > > > > > > > I agree with the problem, but I fail to see why this issue would be > > > > > specific to USB. Shouldn't this be done in the device core layer? > > > > > > > > Only for drivers that are on the block-device writeback path. The > > > > device core doesn't know which drivers these are. > > > > > > Neither does USB know. It is very hard to predict or even tell which > > > devices are block device drivers. I think we must assume that > > > any device may be affected. > > > > All right. Would you like to submit a patch? > > Do you like this one? Hmmm. I might be inclined to move the start of the I/O-protected region a little earlier. For example, the first blocking_notifier_call_chain() might result in some memory allocations. The end is okay; once bus_remove_device() has returned the driver will be completely unbound, so there shouldn't be any pending I/O through the device. Alan Stern
