On Thu, 2018-01-11 at 10:23 +0800, Ming Lei wrote: > > not sufficient to prevent .queuecommand() calls from scsi_send_eh_cmnd(). > > Given it is error handling, do we need to prevent the .queuecommand() call > in scsi_send_eh_cmnd()? Could you share us what the actual issue > observed is from user view?
Please have a look at the kernel bug report in the description of patch 4/4 of this series. > > Hence surround the .queuecommand() call from the SCSI error handler with > > blk_start_wait_if_quiesced() / blk_finish_wait_if_quiesced(). > > > > Note: converting the .queuecommand() call in scsi_send_eh_cmnd() into > > code that calls blk_get_request(), e.g. scsi_execute_req(), is not an > > option since scsi_send_eh_cmnd() can be called if all requests are > > allocated and if no requests will make progress without aborting any > > of these requests. > > If we need to prevent the .queuecommand() in scsi_send_eh_cmnd(), what > do you think of the approach by requeuing the EH command via > scsi_mq_requeue_cmd()/scsi_requeue_cmd()? And the EH request will be > dispatched finally when the queue becomes unquiesced or the STOPPED > is cleared. Calling scsi_mq_requeue_cmd() would trigger scsi_mq_uninit_cmd(), blk_mq_put_driver_tag(), blk_mq_get_driver_tag() and scsi_mq_prep_fn(). That could cause scsi_eh_scmd_add() to be called multiple times for the same SCSI command. However, that would break one of the assumptions scsi_eh_scmd_add() is based on, namely that that function gets called only once per SCSI command that is in progress. Bart.
