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;
Message-ID: <64689ca9-62eb-27e1-63df-e2e8c1a59cbb@oracle.com>
Date:   Sat, 22 Oct 2022 22:21:59 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.3
Subject: Re: [PATCH v4] scsi:iscsi: Fix multiple iscsi session unbind event
 sent to userspace
To:     Wenchao Hao <haowenchao@huawei.com>, Lee Duncan <lduncan@suse.com>,
        Chris Leech <cleech@redhat.com>,
        "James E . J . Bottomley" <jejb@linux.ibm.com>,
        "Martin K . Petersen" <martin.petersen@oracle.com>,
        linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Cc:     Steffen Maier <maier@linux.ibm.com>, liuzhiqiang26@huawei.com,
        linfeilong@huawei.com
References: <20221021235754.1968981-1-haowenchao@huawei.com>
 <daa60cf0-0dde-ea2d-211a-70a9e0efc1b8@oracle.com>
 <2adeb439-646b-ebb1-b266-c3ed4750eac2@huawei.com>
Content-Language: en-US
From:   Mike Christie <michael.christie@oracle.com>
In-Reply-To: <2adeb439-646b-ebb1-b266-c3ed4750eac2@huawei.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?U2NMN0dsaUZReS9EWmtYelZaNm1wQTNuVFA3OTNCT0VaWUJWWGVuTzR0Y1ho?=
 =?utf-8?B?Y0psdS9pdEk5bVRRRWxXcUcrN2x6MzBvSUM2aU9ENkFKQTZkRVVFdXNEdHgx?=
 =?utf-8?B?bjJGVmxvajFmVWlTaDF3bEJGUXRtL0xld3dIUy9rUDNtUW9nSldON2UrMjJ6?=
 =?utf-8?B?VGljRkZrVzJpSCtCallrUVp2ampsSU1WYldva0FDWWYrdGFwaWdVRHpWaFdR?=
 =?utf-8?B?bE0yQkhscytNRFlXcVRqUy9tL3UrWjh1c1NpR0xGd1ZQeStSUDlQb2NabGNn?=
 =?utf-8?B?bkNZSi9Vek5LdmhzcHR1OHNGSFZpbmxPZklDOFpKQ0Y4SjJaQ05oS1NBYTM5?=
 =?utf-8?B?SkVDRkNJSmluS25yT2MzSEZDcGJqM3BUZFJZb2VmQmZUSGRxSk8rOVArMGph?=
 =?utf-8?B?dURvRy9jK01TOWFHSnFVOHNOdWdqZHU3c3BGVU5UWldpZzFzaVVvb1BCRTcw?=
 =?utf-8?B?d1hDcFZ6Sm9pSGVvbDZOVkQyM1RqdVB3a1NwVHlGZVpyUnRBN2FxQXduTERX?=
 =?utf-8?B?UU4yNWRraWFkWXlMMWJNNmRXN1B3eWFsNWk2dUFRRksrZUZoODVaR3FqOVQz?=
 =?utf-8?B?OVpoOFFScGUwYzVTWEZ6QUdNVVRsY21FZ1lPeE5QVVZYcEVNQnU5cjRmM1lQ?=
 =?utf-8?B?VTRpNUtRSTA0WmdHNnBzdHFrbDlPOFAzaVlPSld5Q25zNjNsUW5wRWhIK2Jm?=
 =?utf-8?B?YlBOOU1NaS9hR3JrV2pyQ1hRR3lZb3RyQ1FRV1JqMFloSkg4TmtZU05BYW51?=
 =?utf-8?B?QitwRXgvVzRIUUhpbkZRNEZjbVZnWVpnN0VJdTVmNzF2MFJ3bzVRazF1REVC?=
 =?utf-8?B?bTllWFFzN2QzQWtpN0YrNmxCQ0ZFQWUrU0h2Nnh1bGlHTzZWeDQ3ZlNNR0ZP?=
 =?utf-8?B?T3RhTFpNa2xzdWJFL1JyRzNJcTRPUSszd1hZOW4yZm9SZDNOS3dLb3BhUUUr?=
 =?utf-8?B?MnhqMHRLektBUHJaV3lPU25NNUhTZmJzZWZucnZ0R0dja1F5QXpKWjV6dGdT?=
 =?utf-8?B?Q1QxVXNUUDhaZzJEOU1VMW15d1VaSStlRERlV0RvZ0dGd2taY0RFRWgwQ0ZG?=
 =?utf-8?B?TVoxQmdYQ3NIWGdnQXBaQVZMTzJSd05LZElLKzA0UkVIeHFoUVVvVDBJUlVq?=
 =?utf-8?B?THltQzhKWnJZQ2lQZHpGVEdnRG9HKzJla1d2UUFveHhJMTVCZ2J1L3JrdS9D?=
 =?utf-8?B?cjhhUGEySzFQaDNaandhQWxPbmdqQkVTMHI4Nm1rU3JSV3g1MmRYdjJiM2tS?=
 =?utf-8?B?SnBnTDZIMXBmM2UvRW5LS0hKUUN5MDZ0bXZXN3R4S0JOemQ3WWorRWtKRmQ2?=
 =?utf-8?B?SjF5NXpKWUVVMzJFeGlqMW5nV2Y5OEsxaXluM1VoSHVIRWVTU3J5ckpxeWRs?=
 =?utf-8?B?WnViMHVOUm8vcU1vamwybTd6eWx3RTQrRVpVVy9kZGhiRGFraXhBemhxZDRH?=
 =?utf-8?B?UXpsLzFRMFBZRjlGandNMnVVd0lCU0V6SXE0ZE5OeGRCTTJUREV4dVI2R1RJ?=
 =?utf-8?B?R0NaTVFrbll5Y0F0WTJoTWZCWm9CVCtEcnE5ZUJ2QTV3dVJKcnkrK3AwT3VZ?=
 =?utf-8?B?ZndWYTRZS2t5VkYwTjZwVXo2Z3RKRmxCck1wZmlib0pMWkZpZ3Awd2hqT0xy?=
 =?utf-8?B?SUk3c3B3bjdQbSttT05uVWhhWEQ2TUExaGlBSkV4bXZQK3VGK0ZyUXhYQjg1?=
 =?utf-8?B?WW12ZXlNWTF2cG40MHpWRlBHaHdaM21YanVMQTk2Y3o3RDdZdEFEcTVBMHI4?=
 =?utf-8?B?eEQ1b25XbmhxRGNSVXUyeHFaM1hjQXpRcEdqRWdtVTF1bThPWWdQSnNFMmQ2?=
 =?utf-8?B?L0J0K2JIamFUMDk2amZhWWFvemhBS1d6K01DcWRUUnUrR2lGeVcrWWNEeUNV?=
 =?utf-8?B?SUh3YWZhTlRwMDgyR1J1SzBTVjRtUWJaVnhQM2ovbml2dDdsV3VCYlBXSUZF?=
 =?utf-8?B?MjJOS0NUVXJ4Q3NIUk5NVzY0UzQxbE5laXByR1A4Wkk1NVY3ZnlXVXRBMmN4?=
 =?utf-8?B?enJJS1hHWTJPMTlsbm9ydkZDK0xZNUxVTllEQ1VEcXBocG8xZWJlTk5QYUV2?=
 =?utf-8?B?SCtoajAzNjN5NTFHaVJDQTU2Sm1oN2IrZkN5eTFoa09aMWtjZ3VXYjdtUm9N?=
 =?utf-8?B?UG52SE1hQlduWTBaZVM3eG14RzNlQm5XNEhEcnN0Q0QzeG9QeGM0dHJnTFM2?=
 =?utf-8?B?SFE9PQ==?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7eef439d-f7a9-400f-aa28-08dab4a5c09b
X-MS-Exchange-CrossTenant-AuthSource: DM5PR10MB1466.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2022 03:22:02.1470
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /Km62iMzz4lh0HNJWbiLvInom7H03JWUFAmrIzFYWHTu2fwgLd7cSwDT0Gq6HNtFdQjmoAoK4tAhh9HK/Kj1GasuWnBWlmEF34p0HjMQRPw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4324
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-10-21_04,2022-10-21_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0
 mlxlogscore=999 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2209130000 definitions=main-2210230020
X-Proofpoint-GUID: bMGQgHgWUrDWN1LgXgv2lbaeJMAVY4DM
X-Proofpoint-ORIG-GUID: bMGQgHgWUrDWN1LgXgv2lbaeJMAVY4DM
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.