On Sat, Oct 19, 2024 at 10:50:10PM +0900, Sergey Senozhatsky wrote: > On (24/10/19 21:09), Ming Lei wrote: > > On Sat, Oct 19, 2024 at 09:58:04PM +0900, Sergey Senozhatsky wrote: > > > On (24/10/19 20:50), Ming Lei wrote: > > > > On Sat, Oct 19, 2024 at 09:37:27PM +0900, Sergey Senozhatsky wrote: > [..] > > > > Then we need to root-cause it first. > > > > If you can reproduce it > > I cannot. > > All I'm having are backtraces from various crash reports, I posted > some of them earlier [1] (and in that entire thread). This loos like > close()->bio_queue_enter() vs usb_disconnect()->del_gendisk() deadlock, > and del_gendisk() cannot drain. Doing drain under the same lock, that > things we want to drain currently hold, looks troublesome in general. > > [1] https://lore.kernel.org/linux-block/20241008051948.GB10794@xxxxxxxxxx Probably bio_queue_enter() waits for runtime PM, and the queue is in ->pm_only state, and BLK_MQ_REQ_PM isn't passed actually from ioctl_internal_command() <- scsi_set_medium_removal(). And if you have vmcore collected, it shouldn't be not hard to root cause. Also I'd suggest to collect intact related dmesg log in future, instead of providing selective log, such as, there isn't even kernel version... Thanks, Ming
