On Fri, Sep 14, 2018 at 11:40 AM jianchao.wang
[off-list ref] wrote:

Hi Ming

On 09/13/2018 08:15 PM, Ming Lei wrote:

quoted

 EXPORT_SYMBOL(__scsi_execute);

@@ -3246,6 +3251,7 @@ static int scsi_internal_device_block(struct scsi_device *sdev)
              else
                      scsi_wait_for_queuecommand(sdev);
      }
+     wait_event(sdev->admin_wq, !atomic_read(&sdev->nr_admin_pending));
      mutex_unlock(&sdev->state_mutex);

      return err;

...

quoted

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 3aee9464a7bf..8bcb7ecc0c06 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c

@@ -1393,6 +1393,7 @@ void __scsi_remove_device(struct scsi_device *sdev)

      blk_cleanup_queue(sdev->request_queue);
      cancel_work_sync(&sdev->requeue_work);
+     wait_event(sdev->admin_wq, !atomic_read(&sdev->nr_admin_pending))

This nr_admin_pending could drain the ongoing scsi_request_fn/scsi_queue_rq,
but I'm afraid it cannot stop new ones coming in, such as the ones that have passed
the sdev state checking and have not crossed the atomic_inc(&sdev->nr_admin_pending).

The counter of .nr_admin_pending is introduced for draining queued
admin requests to this scsi device.

Actually new requests have been prevented from entering scsi_queue_rq(),
please see the two callers of wait_event(sdev->admin_wq,
!atomic_read(&sdev->nr_admin_pending)).

Thanks,
Ming Lei