On 11/22/22 11:29 AM, Wenchao Hao wrote:
> On Wed, Nov 23, 2022 at 1:04 AM Mike Christie
> <michael.chris...@oracle.com> wrote:
>>
>> On 11/21/22 8:17 AM, Wenchao Hao wrote:
>>> And the function looks like following after change:
>>>
>>> static void __iscsi_unbind_session(struct work_struct *work)
>>> {
>>> struct iscsi_cls_session *session =
>>> container_of(work, struct iscsi_cls_session,
>>> unbind_work);
>>> struct Scsi_Host *shost = iscsi_session_to_shost(session);
>>> struct iscsi_cls_host *ihost = shost->shost_data;
>>> unsigned long flags;
>>> unsigned int target_id;
>>>
>>> ISCSI_DBG_TRANS_SESSION(session, "Unbinding session\n");
>>>
>>> /* Prevent new scans and make sure scanning is not in progress */
>>> mutex_lock(&ihost->mutex);
>>> spin_lock_irqsave(&session->lock, flags);
>>> if (session->target_state != ISCSI_SESSION_TARGET_SCANNED) {
>>
>> What was the reason for not checking for ALLOCATED and freeing the ida
>> in that case?
>>
>
> target_state would be in "ALLOCATED" state if iscsid died after add
> session successfully.
> When iscsid restarted, if the session's target_state is "ALLOCATED",
> it should scan
> the session and the target_state would switch to "SCANNED".
>
> So I think we would not call in __iscsi_unbind_session() with
> session's target_state
> is ALLOCATED.
Makes sense for the normal case.
The only issue is when __iscsi_unbind_session is called via
iscsi_remove_session for the cases where userspace didn't do
the UNBIND event. Some tools don't do unbind or open-iscsi
sometimes doesn't if the session is down. We will leak the ida,
so you need some code to handle that.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/open-iscsi/856ccad2-19a4-32b4-b41f-5a230a55ee30%40oracle.com.
