From patchwork Sat Jan 28 09:41:45 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: zhongjinghua X-Patchwork-Id: 13119816 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D5E6C61DA7 for ; Sat, 28 Jan 2023 09:17:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232579AbjA1JRu (ORCPT ); Sat, 28 Jan 2023 04:17:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230474AbjA1JRt (ORCPT ); Sat, 28 Jan 2023 04:17:49 -0500 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4CDF4EE1; Sat, 28 Jan 2023 01:17:46 -0800 (PST) Received: from kwepemm600002.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4P3pdV72G9zJqH1; Sat, 28 Jan 2023 17:13:18 +0800 (CST) Received: from localhost.localdomain (10.175.127.227) by kwepemm600002.china.huawei.com (7.193.23.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Sat, 28 Jan 2023 17:17:43 +0800 From: Zhong Jinghua To: , , , , , CC: , , , , Subject: [PATCH-next v2 1/2] driver core: introduce get_device_unless_zero() Date: Sat, 28 Jan 2023 17:41:45 +0800 Message-ID: <20230128094146.205858-2-zhongjinghua@huawei.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20230128094146.205858-1-zhongjinghua@huawei.com> References: <20230128094146.205858-1-zhongjinghua@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm600002.china.huawei.com (7.193.23.29) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org When the dev reference count is 0, calling get_device will go from 0 to 1, which will cause errors in some place of the kernel. So introduce a get_devcie_unless_zero method that returns NULL when the dev reference count is 0. Signed-off-by: Zhong Jinghua --- drivers/base/core.c | 8 ++++++++ include/linux/device.h | 1 + 2 files changed, 9 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index d02501933467..6f17a93a3443 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -3613,6 +3613,14 @@ struct device *get_device(struct device *dev) } EXPORT_SYMBOL_GPL(get_device); +struct device __must_check *get_device_unless_zero(struct device *dev) +{ + if (!dev || !kobject_get_unless_zero(&dev->kobj)) + return NULL; + return dev; +} +EXPORT_SYMBOL_GPL(get_device_unless_zero); + /** * put_device - decrement reference count. * @dev: device in question. diff --git a/include/linux/device.h b/include/linux/device.h index 424b55df0272..c63bac6d51c8 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -1069,6 +1069,7 @@ extern int (*platform_notify_remove)(struct device *dev); * */ struct device *get_device(struct device *dev); +struct device __must_check *get_device_unless_zero(struct device *dev); void put_device(struct device *dev); bool kill_device(struct device *dev); From patchwork Sat Jan 28 09:41:46 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: zhongjinghua X-Patchwork-Id: 13119817 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4D84C38142 for ; Sat, 28 Jan 2023 09:17:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233018AbjA1JRw (ORCPT ); Sat, 28 Jan 2023 04:17:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232174AbjA1JRu (ORCPT ); Sat, 28 Jan 2023 04:17:50 -0500 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B0995B85; Sat, 28 Jan 2023 01:17:47 -0800 (PST) Received: from kwepemm600002.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4P3phN0sLFz16NNH; Sat, 28 Jan 2023 17:15:48 +0800 (CST) Received: from localhost.localdomain (10.175.127.227) by kwepemm600002.china.huawei.com (7.193.23.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Sat, 28 Jan 2023 17:17:44 +0800 From: Zhong Jinghua To: , , , , , CC: , , , , Subject: [PATCH-next v2 2/2] scsi: fix iscsi rescan fails to create block device Date: Sat, 28 Jan 2023 17:41:46 +0800 Message-ID: <20230128094146.205858-3-zhongjinghua@huawei.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20230128094146.205858-1-zhongjinghua@huawei.com> References: <20230128094146.205858-1-zhongjinghua@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm600002.china.huawei.com (7.193.23.29) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org When the three iscsi operations delete, logout, and rescan are concurrent at the same time, there is a probability of failure to add disk through device_add_disk(). The concurrent process is as follows: T0: scan host // echo 1 > /sys/devices/platform/host1/scsi_host/host1/scan T1: delete target // echo 1 > /sys/devices/platform/host1/session1/target1:0:0/1:0:0:1/delete T2: logout // iscsiadm -m node --login T3: T2 scsi_queue_work T4: T0 bus_probe_device T0 T1 T2 T3 scsi_scan_target mutex_lock(&shost->scan_mutex); __scsi_scan_target scsi_report_lun_scan scsi_add_lun scsi_sysfs_add_sdev device_add kobject_add //create session1/target1:0:0/1:0:0:1/ ... bus_probe_device // Create block asynchronously mutex_unlock(&shost->scan_mutex); sdev_store_delete scsi_remove_device device_remove_file mutex_lock(scan_mutex) __scsi_remove_device res = scsi_device_set_state(sdev, SDEV_CANCEL) iscsi_if_recv_msg scsi_queue_work __iscsi_unbind_session session->target_id = ISCSI_MAX_TARGET __scsi_remove_target sdev->sdev_state == SDEV_CANCEL continue; // end, No delete kobject 1:0:0:1 iscsi_if_recv_msg transport->destroy_session(session) __iscsi_destroy_session iscsi_session_teardown iscsi_remove_session __iscsi_unbind_session iscsi_session_event device_del // delete session T4: // create the block, its parent is 1:0:0:1 // If kobject 1:0:0:1 does not exist, it won't go down __device_attach_async_helper device_lock ... __device_attach_driver driver_probe_device really_probe sd_probe device_add_disk register_disk device_add // error The block is created after the seesion is deleted. When T2 deletes the session, it will mark block'parent 1:0:01 as unusable: T2 device_del kobject_del sysfs_remove_dir __kernfs_remove // Mark the children under the session as unusable while ((pos = kernfs_next_descendant_post(pos, kn))) if (kernfs_active(pos)) atomic_add(KN_DEACTIVATED_BIAS, &pos->active); Then, create the block: T4 device_add kobject_add kobject_add_varg kobject_add_internal create_dir sysfs_create_dir_ns kernfs_create_dir_ns kernfs_add_one if ((parent->flags & KERNFS_ACTIVATED) && !kernfs_active(parent)) goto out_unlock; // return error This error will cause a warning: kobject_add_internal failed for block (error: -2 parent: 1:0:0:1). In the lower version (such as 5.10), there is no corresponding error handling, continuing to go down will trigger a kernel panic, so cc stable. Therefore, creating the block should not be done after deleting the session. More practically, we should ensure that the target under the session is deleted first, and then the session is deleted. In this way, there are two possibilities: 1) if the process(T1) of deleting the target execute first, it will grab the device_lock(), and the process(T4) of creating the block will wait for the deletion to complete. Then, block's parent 1:0:0:1 has been deleted, it won't go down. 2) if the process(T4) of creating block execute first, it will grab the device_lock(), and the process(T1) of deleting the target will wait for the creation block to complete. Then, the process(T2) of deleting the session should need wait for the deletion to complete. Fix it by removing the judgment of state equal to SDEV_CANCEL in __scsi_remove_target() to ensure the order of deletion. Then, it will wait for T1's mutex_lock(scan_mutex) and device_del() in __scsi_remove_device() will wait for T4's device_lock(dev). But we found that such a fix would cause the previous problem: commit 81b6c9998979 ("scsi: core: check for device state in __scsi_remove_target()"). So we use get_device_unless_zero() instead of get_devcie() to fix the previous problem. Fixes: 81b6c9998979 ("scsi: core: check for device state in __scsi_remove_target()") Cc: Signed-off-by: Zhong Jinghua --- drivers/scsi/scsi_sysfs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index cac7c902cf70..a22109cdb8ef 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -1535,9 +1535,7 @@ static void __scsi_remove_target(struct scsi_target *starget) if (sdev->channel != starget->channel || sdev->id != starget->id) continue; - if (sdev->sdev_state == SDEV_DEL || - sdev->sdev_state == SDEV_CANCEL || - !get_device(&sdev->sdev_gendev)) + if (!get_device_unless_zero(&sdev->sdev_gendev)) continue; spin_unlock_irqrestore(shost->host_lock, flags); scsi_remove_device(sdev);