Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221108014414.3510940-1-haowenchao@huawei.com>
 <ad54a5dc-b18f-e0e6-4391-1214e5729562@oracle.com> <89692b2b-90f7-e8e8-fa77-f14dbe996b72@huawei.com>
 <418c7f6f-0bc3-45bb-2abf-e866df6f4b62@oracle.com>
In-Reply-To: <418c7f6f-0bc3-45bb-2abf-e866df6f4b62@oracle.com>
From:   Wenchao Hao <haowenchao22@gmail.com>
Date:   Wed, 23 Nov 2022 01:29:10 +0800
Message-ID: <CAOptpSO6=sUPUwgj1og8088djiNA=Bw9um0p024L=0Gb=-ja5w@mail.gmail.com>
Subject: Re: [PATCH v6] scsi:iscsi: Fix multiple iscsi session unbind event
 sent to userspace
To:     Mike Christie <michael.christie@oracle.com>
Cc:     Wenchao Hao <haowenchao@huawei.com>, Lee Duncan <lduncan@suse.com>,
        Chris Leech <cleech@redhat.com>,
        "Martin K . Petersen" <martin.petersen@oracle.com>,
        "James E . J . Bottomley" <jejb@linux.ibm.com>,
        open-iscsi@googlegroups.com, linux-scsi@vger.kernel.org,
        linux-kernel@vger.kernel.org, linfeilong@huawei.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Nov 23, 2022 at 1:04 AM Mike Christie
<michael.christie@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.