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

[Mike Christie <michael.christie@oracle.com>]

On 10/22/22 4:40 AM, Wenchao Hao wrote:
> 
> 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.
> 

For iscsi, that target id is only a number that's used on the initiator side
to track the target. The target has no idea what it is and it's never
sent/used/passed to the target.

For example, the qla4xxx driver uses it to lookup persistent target info it
has stored on it's flash. The other use is that we need a unique name for
the target in sysfs and that target id is used as part of that name.