Re: [PATCH v4] scsi:iscsi: Fix multiple iscsi session unbind event sent to userspace

[Wenchao Hao <haowenchao@huawei.com>]

On 2022/10/22 1:24, Mike Christie wrote:
> On 10/21/22 6:57 PM, Wenchao Hao wrote:
>> +
>>  int iscsi_session_chkready(struct iscsi_cls_session *session)
>>  {
>>  	int err;
>> @@ -1899,6 +1922,7 @@ static void __iscsi_unblock_session(struct work_struct *work)
>>  	cancel_delayed_work_sync(&session->recovery_work);
>>  	spin_lock_irqsave(&session->lock, flags);
>>  	session->state = ISCSI_SESSION_LOGGED_IN;
>> +	session->target_state = ISCSI_SESSION_TARGET_BOUND;
>>  	spin_unlock_irqrestore(&session->lock, flags);
>>  	/* start IO */
> 
> Hey,
> 
> Sorry for the late reply.
> 

It doesn't matter.

> For the initial login we have not scanned the session above, so there
> is no target yet. If iscsid is restarted at this time, then iscsid wants
> to sync the session and also do the initial scan.
> 
> To handle that case and also better match the state names with the
> session's target state we can:
> 
> 1. Move the above line to iscsi_user_scan_session after we have scanned
> the target.
> 2. Add a new state ISCSI_SESSION_TARGET_ALLOCATED to reflect we have
> allocated the target_id, but not yet scanned.
> .

I have some wonder about the target_id like be2iscsi which allocated from 
iscsi_sess_ida. Should not we get the target_id from iSCSI target?
If they allocate target_id with an random value, how to handle the
iscsi_user_scan_session which would check the session's target_id.

I have no environment which deployed these iSCSI drivers like be2iscsi, so I
can not valid my guess.