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.
