Message ID | 9857609999c5b7196417474938a7a09892cd1612.1701104870.git.daniel@makrotopia.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce62:0:b0:403:3b70:6f57 with SMTP id o2csp3299472vqx; Mon, 27 Nov 2023 09:10:00 -0800 (PST) X-Google-Smtp-Source: AGHT+IFgzCGRm9fu6w0f6m1Qc9vrhGzU6lGp2Dbx/2OP7YYKrVG9+ghNkFj6qtSq+cAGUpNNCOXH X-Received: by 2002:a05:6870:2182:b0:1f9:8f1b:86f7 with SMTP id l2-20020a056870218200b001f98f1b86f7mr15231617oae.42.1701105000161; Mon, 27 Nov 2023 09:10:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701105000; cv=none; d=google.com; s=arc-20160816; b=YOxlOWTQyAqvPWC/PSvjvsLg0aiVqEk95E8pjg+5rH8Mb2KHqsrg2wMpBEgtVESWK2 wLb6Zq2kY0AGQV9tipx3++Go0liv6OoJ0tWY7BRrqhHfhx7X6qp7cdznQDGZKOZFZiK0 BDpX4y5rmFZ7+p77sTacB0zkVApEQUtecBgByOwB3SFBEitedJlNzmseKeo1QjZ2YaQy 7YZzVsTdp5ZK8gTqbTnrJIBfxJkd/1C3xBEAUB92ikgYl6f6HegCe4brOWNf9/wZxPGi huQ8R0tdIzKQzFA6lOO44qFqdpkxIwPEWVQwEoMEzJqK/+fFXvCxhlU8jEVF0FX/5ojJ vYEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date; bh=ggrXXD/dXwcDUQn2mTxpkBNzX2R1kLFF2C/aU7m+cF8=; fh=1cUxSKnAJYlPGtS7hWVfdTlh8HlIj9DalcMHjJNLXBI=; b=cT9Oe3acYI9bL5LSeBkMtrsUYEv80omP18js3SLQZpK2Qo/NXrlEe4mN99eJtQsz4F 9w+Z92kuEubilGdtmY2rsOZ1Dr2+7AQSxKoWMOklkWc25aDA4yVFcOfYYgGl8Kxcplri vVsSf29ZhhvFEZqPqDB38cC6Sq5VfBwzYhNycxDP/crpfHEaH5lHcXLe2N6BXTbAApZq s3cus0WMnLVegCap7GTShkUK0iiEvhhS6GXJ/95MorEg+yU9pO6Zw1ioeAXHbKtPhn7R LLepiX4Vrzt/wS4O4xGaZWOsrgHTZJzTb7+z4TD4XfachZiV94PO/uBNjLYETbEpkp6Y W14g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id df4-20020a056830478400b006d8146b35e2si2014995otb.338.2023.11.27.09.09.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Nov 2023 09:10:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 284E2809D44A; Mon, 27 Nov 2023 09:09:55 -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 S1343489AbjK0RJg (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Mon, 27 Nov 2023 12:09:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234700AbjK0RJ0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 27 Nov 2023 12:09:26 -0500 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E981010F6 for <linux-kernel@vger.kernel.org>; Mon, 27 Nov 2023 09:09:31 -0800 (PST) Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.96.2) (envelope-from <daniel@makrotopia.org>) id 1r7f6n-000892-22; Mon, 27 Nov 2023 17:09:22 +0000 Date: Mon, 27 Nov 2023 17:09:14 +0000 From: Daniel Golle <daniel@makrotopia.org> To: Richard Weinberger <richard@nod.at>, Miquel Raynal <miquel.raynal@bootlin.com>, Vignesh Raghavendra <vigneshr@ti.com>, Artem Bityutskiy <Artem.Bityutskiy@nokia.com>, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Cc: John Crispin <john@phrozen.org> Subject: [PATCH] ubi: don't decrease ubi->ref_count on detach error Message-ID: <9857609999c5b7196417474938a7a09892cd1612.1701104870.git.daniel@makrotopia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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]); Mon, 27 Nov 2023 09:09:55 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783737876802653873 X-GMAIL-MSGID: 1783737876802653873 |
Series |
ubi: don't decrease ubi->ref_count on detach error
|
|
Commit Message
Daniel Golle
Nov. 27, 2023, 5:09 p.m. UTC
If attempting to detach a UBI device while it is still busy, detaching
is refused. However, the reference counter is still being decreased
despite the error. Rework detach function to only decrease the refcnt
once all conditions for detachment are met.
Fixes: cdfa788acd13 ("UBI: prepare attach and detach functions")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/mtd/ubi/build.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
----- Ursprüngliche Mail ----- > Von: "Daniel Golle" <daniel@makrotopia.org> > An: "richard" <richard@nod.at>, "Miquel Raynal" <miquel.raynal@bootlin.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, > "Artem Bityutskiy" <Artem.Bityutskiy@nokia.com>, "linux-mtd" <linux-mtd@lists.infradead.org>, "linux-kernel" > <linux-kernel@vger.kernel.org> > CC: "John Crispin" <john@phrozen.org> > Gesendet: Montag, 27. November 2023 18:09:14 > Betreff: [PATCH] ubi: don't decrease ubi->ref_count on detach error > If attempting to detach a UBI device while it is still busy, detaching > is refused. However, the reference counter is still being decreased > despite the error. Rework detach function to only decrease the refcnt > once all conditions for detachment are met. > > Fixes: cdfa788acd13 ("UBI: prepare attach and detach functions") > Signed-off-by: Daniel Golle <daniel@makrotopia.org> Good catch! Did you find this by review or while testing? > --- > drivers/mtd/ubi/build.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > index 7d4ff1193db6f..f47987ee9a31b 100644 > --- a/drivers/mtd/ubi/build.c > +++ b/drivers/mtd/ubi/build.c > @@ -1099,16 +1099,16 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway) > > spin_lock(&ubi_devices_lock); > put_device(&ubi->dev); > - ubi->ref_count -= 1; > - if (ubi->ref_count) { > + if (ubi->ref_count > 1) { Is there a specific reason why you have modified the check to test only for ref_count being positive? If rec_counts turns negative, due to a bug, we could still stop it here. > if (!anyway) { > spin_unlock(&ubi_devices_lock); > return -EBUSY; > } > /* This may only happen if there is a bug */ > ubi_err(ubi, "%s reference count %d, destroy anyway", > - ubi->ubi_name, ubi->ref_count); > + ubi->ubi_name, ubi->ref_count - 1); > } > + ubi->ref_count -= 1; Please add there an ubi_asert() which tests whether ref_count is really zero. ...just to be more bullet proof. Thanks, //richard
Hi Richard, On Mon, Nov 27, 2023 at 09:25:58PM +0100, Richard Weinberger wrote: > > If attempting to detach a UBI device while it is still busy, detaching > > is refused. However, the reference counter is still being decreased > > despite the error. Rework detach function to only decrease the refcnt > > once all conditions for detachment are met. > > > > Fixes: cdfa788acd13 ("UBI: prepare attach and detach functions") > > Signed-off-by: Daniel Golle <daniel@makrotopia.org> > > Good catch! Did you find this by review or while testing? I was working on simplifying the NVMEM-on-UBI code which includes attaching UBI via MTD notifiers. You and others had rightously criticized the sketchy situation of the 'remove' handler which has now lead me to rework that part of my patches, which made me end up looking at the ref_count logic and error path at some point it popped into my eyes that this can't be right. > > > --- > > drivers/mtd/ubi/build.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > > index 7d4ff1193db6f..f47987ee9a31b 100644 > > --- a/drivers/mtd/ubi/build.c > > +++ b/drivers/mtd/ubi/build.c > > @@ -1099,16 +1099,16 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway) > > > > spin_lock(&ubi_devices_lock); > > put_device(&ubi->dev); > > - ubi->ref_count -= 1; > > - if (ubi->ref_count) { > > + if (ubi->ref_count > 1) { > > Is there a specific reason why you have modified the check to test only > for ref_count being positive? My idea was to really change only what I meant to change and make that change the least intrusive possible. > If rec_counts turns negative, due to a bug, we could still stop it here. ... here and in every other pleace where we touch it? Adding new sanity checks to the code probably doesn't hurt but goes beyond the scope of fixing this very bug, so I'll only do it there for now. > > > if (!anyway) { > > spin_unlock(&ubi_devices_lock); > > return -EBUSY; > > } > > /* This may only happen if there is a bug */ > > ubi_err(ubi, "%s reference count %d, destroy anyway", > > - ubi->ubi_name, ubi->ref_count); > > + ubi->ubi_name, ubi->ref_count - 1); > > } > > + ubi->ref_count -= 1; > > Please add there an ubi_asert() which tests whether ref_count is really zero. > ...just to be more bullet proof. That makes sense, now that it became clear that ref_count wasn't trustable for more than a decade, let's better make sure it is now.
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 7d4ff1193db6f..f47987ee9a31b 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -1099,16 +1099,16 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway) spin_lock(&ubi_devices_lock); put_device(&ubi->dev); - ubi->ref_count -= 1; - if (ubi->ref_count) { + if (ubi->ref_count > 1) { if (!anyway) { spin_unlock(&ubi_devices_lock); return -EBUSY; } /* This may only happen if there is a bug */ ubi_err(ubi, "%s reference count %d, destroy anyway", - ubi->ubi_name, ubi->ref_count); + ubi->ubi_name, ubi->ref_count - 1); } + ubi->ref_count -= 1; ubi_devices[ubi_num] = NULL; spin_unlock(&ubi_devices_lock);