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.