Alan, On Mon, Dec 17, 2018 at 10:45:17AM -0500, Alan Stern wrote: > On Sun, 16 Dec 2018, Gaël PORTAY wrote: > ... > > > The second task wants to writeback/flush the pages through USB, which, I > > assume, is due to the page migration. The usb-storage triggers a CMA allocation > > but get locked in cma_alloc since the first task hold the mutex (It is a FAT > > formatted partition, if it helps). > > > > usb-storage D 0 349 2 0x00000000 > > Backtrace: > ... > > [<bf1c7550>] (usb_sg_wait [usbcore]) from [<bf2bd618>] (usb_stor_bulk_transfer_sglist.part.2+0x80/0xdc [usb_storage]) r9:0001e000 r8:eca594ac r7:0001e000 r6:c0008200 r5:eca59514 r4:eca59488 > > It looks like there is a logical problem in the CMA allocator. The > call in usb_sg_wait() specifies GFP_NOIO, which is supposed to prevent > allocations from blocking on any I/O operations. Therefore we > shouldn't be waiting for the CMA mutex. > Right. > Perhaps the CMA allocator needs to drop the mutex while doing > writebacks/flushes, or perhaps it needs to be reorganized some other > way. I don't know anything about it. > > Does the CMA code have any maintainers who might need to know about > this, or is it all handled by the MM maintainers? I did not find maintainers neither for CMA nor MM. That is why I have sent this mail to mm mailing list but to no one in particular. > > Alan Stern > Thanks. Regards, Gael
