On Fri, Sep 14, 2018 at 11:40 AM jianchao.wang <jianchao.w.wang@xxxxxxxxxx> wrote: > > Hi Ming > > On 09/13/2018 08:15 PM, Ming Lei wrote: > > 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; > ... > > 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
