All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: Zhihao Cheng <chengzhihao1@huawei.com>
Cc: Ryder W <rydercoding@hotmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] ubi: don't decrease ubi->ref_count on detach error
Date: Tue, 5 Dec 2023 12:23:27 +0000	[thread overview]
Message-ID: <ZW8WP3SB-EARFVW_@makrotopia.org> (raw)
In-Reply-To: <f7e5075e-232c-7e37-348d-71300b10dac8@huawei.com>

On Tue, Dec 05, 2023 at 05:01:36PM +0800, Zhihao Cheng wrote:
> 在 2023/12/5 16:11, Ryder W 写道:
> > > > Fixes: cdfa788acd13 ("UBI: prepare attach and detach functions")
> > > > Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> > > > ---
> > > >   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) {
> > > >   		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);
> > 
> > In the last code of ubi_detach_mtd_dev, the line "ubi->ref_count -= 1" after the line "put_device(&ubi->dev)" is just to decrease ubi->ref_count, which is increased from calling put_device. I don't understand why it should be moved after the sanity check of ubi->ref_count. It may introduce some more critical bug.
> > 
> > 
> 
> Thanks for reminding, you are right. I think I missed the code of
> 'ubi->ref_count' increasing in ubi_get_device, so decreasing the
> 'ubi->ref_count' unconditionally is right. In most cases, the
> 'ubi->ref_count' is zero(unless ubifs is mounted).

Sorry for the noise, I agree, the current code is correct and ref_count
indeed needs to be decreased unconditionally as it has just been
increased by calling ubi_get_device() in the lines above.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2023-12-05 12:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05  8:11 [PATCH] ubi: don't decrease ubi->ref_count on detach error Ryder W
2023-12-05  9:01 ` Zhihao Cheng
2023-12-05 12:23   ` Daniel Golle [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-11-27 17:09 Daniel Golle
2023-11-27 17:09 ` Daniel Golle
2023-11-27 20:25 ` Richard Weinberger
2023-11-27 20:25   ` Richard Weinberger
2023-11-27 22:06   ` Daniel Golle
2023-11-27 22:06     ` Daniel Golle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZW8WP3SB-EARFVW_@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=chengzhihao1@huawei.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rydercoding@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.