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.
