On 7/1/20 12:47 PM, Mike Christie wrote: > If we are doing async removal of the session, we could be doing a > scsi_remove_target from the removal workqueue, and for the offload > case we could be doing a new session addition and scan to the same > host. The add/scan might then end up trying to use the target_id > of the target we are removing. > > This patch just has a delay the freeing of the target_id until after > the scsi_remove_target has completed, so we know it's no longer in > use. Nit: "has a delay" => "delays" > > Signed-off-by: Mike Christie <michael.christie@xxxxxxxxxx> > --- > drivers/scsi/scsi_transport_iscsi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c > index 7ae5024e7824..2cd2610ecfaf 100644 > --- a/drivers/scsi/scsi_transport_iscsi.c > +++ b/drivers/scsi/scsi_transport_iscsi.c > @@ -2036,11 +2036,11 @@ static void __iscsi_unbind_session(struct work_struct *work) > spin_unlock_irqrestore(&session->lock, flags); > mutex_unlock(&ihost->mutex); > > + scsi_remove_target(&session->dev); > + > if (session->ida_used) > ida_simple_remove(&iscsi_sess_ida, target_id); > > - scsi_remove_target(&session->dev); > - > unbind_session_exit: > iscsi_session_event(session, ISCSI_KEVENT_UNBIND_SESSION); > ISCSI_DBG_TRANS_SESSION(session, "Completed target removal\n"); > Reviewed-by: Lee Duncan <lduncan@xxxxxxxx>
