Re: block: del_gendisk() vs blk_queue_enter() race condition

[Sergey Senozhatsky <senozhatsky@chromium.org>]

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.