On (24/10/08 14:19), Sergey Senozhatsky wrote: [..] > Or another report: > > sr 1:0:0:0: Power-on or device reset occurred > sr 1:0:0:0: [sr0] scsi3-mmc drive: 8x/24x writer dvd-ram cd/rw xa/form2 cdda tray > usb 1-1.3.1: USB disconnect, device number 27 > > schedule+0x554/0x1218 > schedule_preempt_disabled+0x30/0x50 > mutex_lock+0x3c/0x70 > del_gendisk+0xe8/0x370 > sr_remove+0x30/0x58 [sr_mod (HASH:d5f2 4)] > device_release_driver_internal+0x1a0/0x278 > device_release_driver+0x24/0x38 > bus_remove_device+0x150/0x170 > device_del+0x1d0/0x348 > __scsi_remove_device+0xb4/0x198 > scsi_forget_host+0x5c/0x80 > scsi_remove_host+0x98/0x1c8 > usb_stor_disconnect+0x74/0x110 > usb_unbind_interface+0xcc/0x250 > device_release_driver_internal+0x1a0/0x278 > device_release_driver+0x24/0x38 > bus_remove_device+0x150/0x170 > device_del+0x1d0/0x348 > usb_disable_device+0x88/0x190 > usb_disconnect+0xf8/0x318 > > schedule+0x554/0x1218 > blk_queue_enter+0xd0/0x170 > blk_mq_alloc_request+0x138/0x1e8 > scsi_execute_cmd+0x88/0x258 > scsi_test_unit_ready+0x88/0x118 > sr_drive_status+0x5c/0x160 [sr_mod (HASH:d5f2 4)] > cdrom_ioctl+0x7d4/0x2730 [cdrom (HASH:37c3 5)] > sr_block_ioctl+0xa8/0x110 [sr_mod (HASH:d5f2 4)] > blkdev_ioctl+0x468/0xbf0 > __arm64_sys_ioctl+0x254/0x6d0 Didn't copy one more backtrace here, there are two mutexes involved. schedule+0x554/0x1218 schedule_preempt_disabled+0x30/0x50 mutex_lock+0x3c/0x70 sr_block_release+0x2c/0x60 [sr_mod (HASH:d5f2 4)] blkdev_put+0x184/0x290 blkdev_release+0x34/0x50 __fput_sync+0xa8/0x2d8 __arm64_sys_close+0x6c/0xd8 invoke_syscall+0x78/0xf0 So process A holds cd->lock and sleeps in blk_queue_enter() process B holds ->open_mutex and sleeps on cd->lock, which is owned by A process C sleeps on ->open_mutex, which is owned by B.
