linux-kernel - Re: [PATCH v4] scsi:iscsi: Fix multiple iscsi session unbind event sent to userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2adeb439-646b-ebb1-b266-c3ed4750eac2@huawei.com>
Date:   Sat, 22 Oct 2022 17:40:21 +0800
From:   Wenchao Hao <haowenchao@...wei.com>
To:     Mike Christie <michael.christie@...cle.com>,
        Lee Duncan <lduncan@...e.com>, Chris Leech <cleech@...hat.com>,
        "James E . J . Bottomley" <jejb@...ux.ibm.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        <linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC:     Steffen Maier <maier@...ux.ibm.com>, <liuzhiqiang26@...wei.com>,
        <linfeilong@...wei.com>
Subject: Re: [PATCH v4] scsi:iscsi: Fix multiple iscsi session unbind event
 sent to userspace


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.