Message ID | 20231208082335.1754205-1-linan666@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp5316459vqy; Fri, 8 Dec 2023 00:25:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IH40YbSj9ifQURPNIzjai5M9JrAYTQza12rMdkTKpVhAiwfjSofVRmEBR16/ZNFycuciKRq X-Received: by 2002:a05:6a20:3b29:b0:190:f53:210c with SMTP id c41-20020a056a203b2900b001900f53210cmr484302pzh.6.1702023901809; Fri, 08 Dec 2023 00:25:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702023901; cv=none; d=google.com; s=arc-20160816; b=zm7XyPo9fgvfmbEWOcRlb0JkNR9AzhwH8zYbI08mSphww1E+gDtz//Dtp1wrJBrJ91 14zFHdKjdMWV7fB+R02rH6oL8vDy4u8FWF1IxZwMMKJV6bIIpJ06aVePkOWDzVBKpeIj ynKj1g216O2xwRyYQVPCPBJQ1SeKScxuPwaJwfyO3w6vaJs0IR4qgD56BJOyVFQKnX34 TcSdLjLUIHeU0JOPrCuiafQL9hAcUB8FNusDUPQGTVP4fwBje7P2SFE5Lxv1lK8Cuk7p BcpyHsUbBNGs+bP/DscUgBqTYm2ilIVZuiTSgCjM73//9AgQS4HxRtlYvfMnZq3iGopD 9VWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=6fBTftYonsRWKNtNI2DhUSxq3v5TFdhih75o14Lf9I0=; fh=7RYUT2J5p7ROu5PBaPpATDCV5+4ZOf67qrQniqToYqw=; b=vCfrLRH6tvUbFQGvARybNU8TxSf/CVHVw12+kQQ2A4MSohTp6JaaXdYpllnImu782G hDtl4WjO/H1grm1s/ExGfR6EObH+C79OBbsueLf5SmzikEceZ9YLcTz219GkIkyOIvgb rqgU/gh+gjFM9hkawmB9adzApia1/pRcpZyeswmNm0a8M3oDT8wMfgnYwlSHx8IH7wB5 Gqu94BQBrUvy05VOZHII/oc5rzj1S7vuUbHMZQgNLKYbBjoHpirB1x43ST+iK8B7ogfN XxCMHJm6tlvgIYRYCIN+Rtusc/tdrRk/oiJZ1KBkv/8CN7BWLOuIaJqtH0E3r6kpqfoC hUFQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id f15-20020a65628f000000b005b9519d9e3esi1155354pgv.242.2023.12.08.00.25.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 00:25:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 509DC80F6482; Fri, 8 Dec 2023 00:24:58 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1573275AbjLHIYs (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Fri, 8 Dec 2023 03:24:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232974AbjLHIYr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 8 Dec 2023 03:24:47 -0500 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60AF61724; Fri, 8 Dec 2023 00:24:53 -0800 (PST) Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4SmkhX66PQz4f3l1b; Fri, 8 Dec 2023 16:24:44 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id A0D891A09BD; Fri, 8 Dec 2023 16:24:49 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgDHyhDP0nJlmB1EDA--.42879S4; Fri, 08 Dec 2023 16:24:49 +0800 (CST) From: linan666@huaweicloud.com To: jejb@linux.ibm.com, martin.petersen@oracle.com, mcgrof@kernel.org Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, linan122@huawei.com, yukuai3@huawei.com, yi.zhang@huawei.com, houtao1@huawei.com, yangerkun@huawei.com Subject: [PATCH] scsi: sd: unregister device if device_add_disk() failed in sd_probe() Date: Fri, 8 Dec 2023 16:23:35 +0800 Message-Id: <20231208082335.1754205-1-linan666@huaweicloud.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: cCh0CgDHyhDP0nJlmB1EDA--.42879S4 X-Coremail-Antispam: 1UD129KBjvdXoW7JFWxXr13GryDXw1DZry7ZFb_yoWfArg_Ca 12v39rXr1rCr1xtw1fAr1avrW0vF42qrW5Cr4jqF9ava15WryvgF909r1Fvr4UGF17uw1U tr1jqr4Fyr4kKjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUba8YFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I6I8E6xAIw20E Y4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwV A0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0cI8IcVCY1x02 67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I 0E14v26rxl6s0DM2vYz4IE04k24VAvwVAKI4IrM2AIxVAIcxkEcVAq07x20xvEncxIr21l 5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67 AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFIxGxcIEc7Cj xVA2Y2ka0xkIwI1lw4CEc2x0rVAKj4xxMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4 AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE 17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMI IF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3 Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcS sGvfC2KfnxnUUI43ZEXa7IUbEAp5UUUUU== X-CM-SenderInfo: polqt0awwwqx5xdzvxpfor3voofrz/ X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 08 Dec 2023 00:24:58 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784701415115810975 X-GMAIL-MSGID: 1784701415115810975 |
Series |
scsi: sd: unregister device if device_add_disk() failed in sd_probe()
|
|
Commit Message
Li Nan
Dec. 8, 2023, 8:23 a.m. UTC
From: Li Nan <linan122@huawei.com> "if device_add() succeeds, you should call device_del() when you want to get rid of it." In sd_probe(), device_add_disk() fails when device_add() has already succeeded, so change put_device() to device_unregister() to ensure device resources are released. Fixes: 2a7a891f4c40 ("scsi: sd: Add error handling support for add_disk()") Signed-off-by: Li Nan <linan122@huawei.com> --- drivers/scsi/sd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Fri, Dec 08, 2023 at 04:23:35PM +0800, linan666@huaweicloud.com wrote: > From: Li Nan <linan122@huawei.com> > > "if device_add() succeeds, you should call device_del() when you want to > get rid of it." > > In sd_probe(), device_add_disk() fails when device_add() has already > succeeded, so change put_device() to device_unregister() to ensure device > resources are released. > > Fixes: 2a7a891f4c40 ("scsi: sd: Add error handling support for add_disk()") > Signed-off-by: Li Nan <linan122@huawei.com> Nacked-by: Luis Chamberlain <mcgrof@kernel.org> > --- > drivers/scsi/sd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index 542a4bbb21bc..d81cbeee06eb 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -3736,7 +3736,7 @@ static int sd_probe(struct device *dev) > > error = device_add_disk(dev, gd, NULL); > if (error) { > - put_device(&sdkp->disk_dev); > + device_unregister(&sdkp->disk_dev); > put_disk(gd); > goto out; > } This is incorrect, device_unregister() calls: void device_unregister(struct device *dev) { pr_debug("device: '%s': %s\n", dev_name(dev), __func__); device_del(dev); put_device(dev); } So you're adding what you believe to be a correct missing device_del(). But what you missed is that if device_add_disk() fails then device_add() did not succeed because the new code we have in the kernel *today* unwinds this for us now. What you missed is that in today's code inside device_add_disk(), if device_add() succeeeds we now unwind and call device_del() for the device for you. And so, quoting the next sentence you took from device_add(): "If device_add() has *not* succeeded, use *only* put_device() to drop the reference count." Please do reference in the future a crash dump / or explain how you reached your conclusions if you do not have a crash dump to prove an issue. Specially if you are suggesting it Fixes a commit. Luis
Hi, 在 2023/12/22 14:49, Luis Chamberlain 写道: > On Fri, Dec 08, 2023 at 04:23:35PM +0800, linan666@huaweicloud.com wrote: >> From: Li Nan <linan122@huawei.com> >> >> "if device_add() succeeds, you should call device_del() when you want to >> get rid of it." >> >> In sd_probe(), device_add_disk() fails when device_add() has already >> succeeded, so change put_device() to device_unregister() to ensure device >> resources are released. >> >> Fixes: 2a7a891f4c40 ("scsi: sd: Add error handling support for add_disk()") >> Signed-off-by: Li Nan <linan122@huawei.com> > > Nacked-by: Luis Chamberlain <mcgrof@kernel.org> > >> --- >> drivers/scsi/sd.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c >> index 542a4bbb21bc..d81cbeee06eb 100644 >> --- a/drivers/scsi/sd.c >> +++ b/drivers/scsi/sd.c >> @@ -3736,7 +3736,7 @@ static int sd_probe(struct device *dev) >> >> error = device_add_disk(dev, gd, NULL); >> if (error) { >> - put_device(&sdkp->disk_dev); >> + device_unregister(&sdkp->disk_dev); >> put_disk(gd); >> goto out; >> } > > This is incorrect, device_unregister() calls: > > void device_unregister(struct device *dev) > { > pr_debug("device: '%s': %s\n", dev_name(dev), __func__); > device_del(dev); > put_device(dev); > } > > So you're adding what you believe to be a correct missing device_del(). > But what you missed is that if device_add_disk() fails then device_add() > did not succeed because the new code we have in the kernel *today* unwinds > this for us now. I'm confused here, there are two device here, one is 'sdkp->disk_dev', one is gendisk->part0->bd_device, and the order in which they initialize: sd_probe device_add(&sdkp->disk_dev) -> succeed device_add_disk -> failed, and device_add(bd_device) did not succeed put_device(&sdkp->disk_dev) -> device_del is missed I don't see that if device_add_disk() fail, device_del() for 'sdkp->disk_dev'is called from anywhere. Do I missing anything? Thanks, Kuai > > What you missed is that in today's code inside device_add_disk(), if > device_add() succeeeds we now unwind and call device_del() for the > device for you. And so, quoting the next sentence you took from > device_add(): > > "If device_add() has *not* succeeded, use *only* put_device() to drop the > reference count." > > Please do reference in the future a crash dump / or explain how you > reached your conclusions if you do not have a crash dump to prove an > issue. Specially if you are suggesting it Fixes a commit. > > Luis > > . >
friendly ping ... 在 2023/12/8 16:23, linan666@huaweicloud.com 写道: > From: Li Nan <linan122@huawei.com> > > "if device_add() succeeds, you should call device_del() when you want to > get rid of it." > > In sd_probe(), device_add_disk() fails when device_add() has already > succeeded, so change put_device() to device_unregister() to ensure device > resources are released. > > Fixes: 2a7a891f4c40 ("scsi: sd: Add error handling support for add_disk()") > Signed-off-by: Li Nan <linan122@huawei.com> > --- > drivers/scsi/sd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index 542a4bbb21bc..d81cbeee06eb 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -3736,7 +3736,7 @@ static int sd_probe(struct device *dev) > > error = device_add_disk(dev, gd, NULL); > if (error) { > - put_device(&sdkp->disk_dev); > + device_unregister(&sdkp->disk_dev); > put_disk(gd); > goto out; > }
On Fri, Dec 22, 2023 at 04:27:16PM +0800, Yu Kuai wrote: > Hi, > > 在 2023/12/22 14:49, Luis Chamberlain 写道: > > On Fri, Dec 08, 2023 at 04:23:35PM +0800, linan666@huaweicloud.com wrote: > > > From: Li Nan <linan122@huawei.com> > > > > > > "if device_add() succeeds, you should call device_del() when you want to > > > get rid of it." > > > > > > In sd_probe(), device_add_disk() fails when device_add() has already > > > succeeded, so change put_device() to device_unregister() to ensure device > > > resources are released. > > > > > > Fixes: 2a7a891f4c40 ("scsi: sd: Add error handling support for add_disk()") > > > Signed-off-by: Li Nan <linan122@huawei.com> > > > > Nacked-by: Luis Chamberlain <mcgrof@kernel.org> > > > > > --- > > > drivers/scsi/sd.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > > > index 542a4bbb21bc..d81cbeee06eb 100644 > > > --- a/drivers/scsi/sd.c > > > +++ b/drivers/scsi/sd.c > > > @@ -3736,7 +3736,7 @@ static int sd_probe(struct device *dev) > > > error = device_add_disk(dev, gd, NULL); > > > if (error) { > > > - put_device(&sdkp->disk_dev); > > > + device_unregister(&sdkp->disk_dev); > > > put_disk(gd); > > > goto out; > > > } > > > > This is incorrect, device_unregister() calls: > > > > void device_unregister(struct device *dev) > > { > > pr_debug("device: '%s': %s\n", dev_name(dev), __func__); > > device_del(dev); > > put_device(dev); > > } > > > > So you're adding what you believe to be a correct missing device_del(). > > But what you missed is that if device_add_disk() fails then device_add() > > did not succeed because the new code we have in the kernel *today* unwinds > > this for us now. > > I'm confused here, there are two device here, one is 'sdkp->disk_dev', > one is gendisk->part0->bd_device, and the order in which they > initialize: > > sd_probe > device_add(&sdkp->disk_dev) -> succeed > device_add_disk -> failed, and device_add(bd_device) did not succeed > put_device(&sdkp->disk_dev) -> device_del is missed > > I don't see that if device_add_disk() fail, device_del() for > 'sdkp->disk_dev'is called from anywhere. Do I missing anything? Ah then the fix is still incorrect and the commit log should describe that this is for another device. How about this instead? From c3f6e03f4a82aa253b6c487a293dcd576393b606 Mon Sep 17 00:00:00 2001 From: Luis Chamberlain <mcgrof@kernel.org> Date: Mon, 29 Jan 2024 09:25:18 -0800 Subject: [PATCH] sd: remove extra put_device() for extra scsi device The sd driver first device_add() its own device, and later use device_add_disk() with another device. When we added error handling for device_add_disk() we now call put_disk() and that will trigger disk_release() when the refcount is 0. That will end up calling the block driver's disk->fops->free_disk() if one is defined. The sd driver has scsi_disk_free_disk() as its free_disk() and that does the proper put_device(&sdkp->disk_dev) for us so we should not need to call it, however we are left still missing the device_del() for it. While at it, unwind with scsi_autopm_put_device(sdp) *prior* to putting to device as we do in sd_remove(). Reported-by: Li Nan <linan122@huawei.com> Reported-by: Yu Kuai <yukuai1@huaweicloud.com> Fixes: 2a7a891f4c40 ("scsi: sd: Add error handling support for add_disk()") Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> --- drivers/scsi/sd.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 7f949adbadfd..6475a3c947f8 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -3693,8 +3693,9 @@ static int sd_probe(struct device *dev) error = device_add(&sdkp->disk_dev); if (error) { + scsi_autopm_put_device(sdp); put_device(&sdkp->disk_dev); - goto out; + return error; } dev_set_drvdata(dev, sdkp); @@ -3734,9 +3735,10 @@ static int sd_probe(struct device *dev) error = device_add_disk(dev, gd, NULL); if (error) { - put_device(&sdkp->disk_dev); + scsi_autopm_put_device(sdp); + device_del(&sdkp->disk_dev); put_disk(gd); - goto out; + return error; } if (sdkp->security) {
Hi, 在 2024/01/30 1:46, Luis Chamberlain 写道: > On Fri, Dec 22, 2023 at 04:27:16PM +0800, Yu Kuai wrote: >> Hi, >> >> 在 2023/12/22 14:49, Luis Chamberlain 写道: >>> On Fri, Dec 08, 2023 at 04:23:35PM +0800, linan666@huaweicloud.com wrote: >>>> From: Li Nan <linan122@huawei.com> >>>> >>>> "if device_add() succeeds, you should call device_del() when you want to >>>> get rid of it." >>>> >>>> In sd_probe(), device_add_disk() fails when device_add() has already >>>> succeeded, so change put_device() to device_unregister() to ensure device >>>> resources are released. >>>> >>>> Fixes: 2a7a891f4c40 ("scsi: sd: Add error handling support for add_disk()") >>>> Signed-off-by: Li Nan <linan122@huawei.com> >>> >>> Nacked-by: Luis Chamberlain <mcgrof@kernel.org> >>> >>>> --- >>>> drivers/scsi/sd.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c >>>> index 542a4bbb21bc..d81cbeee06eb 100644 >>>> --- a/drivers/scsi/sd.c >>>> +++ b/drivers/scsi/sd.c >>>> @@ -3736,7 +3736,7 @@ static int sd_probe(struct device *dev) >>>> error = device_add_disk(dev, gd, NULL); >>>> if (error) { >>>> - put_device(&sdkp->disk_dev); >>>> + device_unregister(&sdkp->disk_dev); >>>> put_disk(gd); >>>> goto out; >>>> } >>> >>> This is incorrect, device_unregister() calls: >>> >>> void device_unregister(struct device *dev) >>> { >>> pr_debug("device: '%s': %s\n", dev_name(dev), __func__); >>> device_del(dev); >>> put_device(dev); >>> } >>> >>> So you're adding what you believe to be a correct missing device_del(). >>> But what you missed is that if device_add_disk() fails then device_add() >>> did not succeed because the new code we have in the kernel *today* unwinds >>> this for us now. >> >> I'm confused here, there are two device here, one is 'sdkp->disk_dev', >> one is gendisk->part0->bd_device, and the order in which they >> initialize: >> >> sd_probe >> device_add(&sdkp->disk_dev) -> succeed >> device_add_disk -> failed, and device_add(bd_device) did not succeed >> put_device(&sdkp->disk_dev) -> device_del is missed >> >> I don't see that if device_add_disk() fail, device_del() for >> 'sdkp->disk_dev'is called from anywhere. Do I missing anything? > > Ah then the fix is still incorrect and the commit log should > describe that this is for another device. > > How about this instead? > >>From c3f6e03f4a82aa253b6c487a293dcd576393b606 Mon Sep 17 00:00:00 2001 > From: Luis Chamberlain <mcgrof@kernel.org> > Date: Mon, 29 Jan 2024 09:25:18 -0800 > Subject: [PATCH] sd: remove extra put_device() for extra scsi device > > The sd driver first device_add() its own device, and later use > device_add_disk() with another device. When we added error handling > for device_add_disk() we now call put_disk() and that will trigger > disk_release() when the refcount is 0. That will end up calling > the block driver's disk->fops->free_disk() if one is defined. The This is incorrect. GD_ADDED will only set when device_add_disk() succeed, and free_disk() will only be called from disk_release() if GD_ADDED is set. I think Li Nan's patch is correct. > sd driver has scsi_disk_free_disk() as its free_disk() and that > does the proper put_device(&sdkp->disk_dev) for us so we should not > need to call it, however we are left still missing the device_del() > for it. > > While at it, unwind with scsi_autopm_put_device(sdp) *prior* to > putting to device as we do in sd_remove(). > > Reported-by: Li Nan <linan122@huawei.com> > Reported-by: Yu Kuai <yukuai1@huaweicloud.com> > Fixes: 2a7a891f4c40 ("scsi: sd: Add error handling support for add_disk()") > Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> > --- > drivers/scsi/sd.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index 7f949adbadfd..6475a3c947f8 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -3693,8 +3693,9 @@ static int sd_probe(struct device *dev) > > error = device_add(&sdkp->disk_dev); > if (error) { > + scsi_autopm_put_device(sdp); > put_device(&sdkp->disk_dev); > - goto out; > + return error; I don't see why this is necessary, the tag 'out' is still there. If you think is a problem, I think you need a separate patch to call scsi_autopm_put_device() before putting the device. Thanks, Kuai > } > > dev_set_drvdata(dev, sdkp); > @@ -3734,9 +3735,10 @@ static int sd_probe(struct device *dev) > > error = device_add_disk(dev, gd, NULL); > if (error) { > - put_device(&sdkp->disk_dev); > + scsi_autopm_put_device(sdp); > + device_del(&sdkp->disk_dev); > put_disk(gd); > - goto out; > + return error; > } > > if (sdkp->security) { >
friendly ping... 在 2023/12/8 16:23, linan666@huaweicloud.com 写道: > From: Li Nan <linan122@huawei.com> > > "if device_add() succeeds, you should call device_del() when you want to > get rid of it." > > In sd_probe(), device_add_disk() fails when device_add() has already > succeeded, so change put_device() to device_unregister() to ensure device > resources are released. > > Fixes: 2a7a891f4c40 ("scsi: sd: Add error handling support for add_disk()") > Signed-off-by: Li Nan <linan122@huawei.com> > --- > drivers/scsi/sd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index 542a4bbb21bc..d81cbeee06eb 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -3736,7 +3736,7 @@ static int sd_probe(struct device *dev) > > error = device_add_disk(dev, gd, NULL); > if (error) { > - put_device(&sdkp->disk_dev); > + device_unregister(&sdkp->disk_dev); > put_disk(gd); > goto out; > }
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 542a4bbb21bc..d81cbeee06eb 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -3736,7 +3736,7 @@ static int sd_probe(struct device *dev) error = device_add_disk(dev, gd, NULL); if (error) { - put_device(&sdkp->disk_dev); + device_unregister(&sdkp->disk_dev); put_disk(gd); goto out; }