All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: u-boot@lists.denx.de
Subject: [PATCH] ubifs: Fix reference count leak in ubifsumount
Date: Mon, 23 May 2022 23:35:50 +0200	[thread overview]
Message-ID: <20220523213550.14570-1-pali@kernel.org> (raw)

Original ubifs code was designed that after ubifs_umount() call it is
required to also call ubi_close_volume() which closes underlying UBI
volume. But U-Boot ubifs modification have not implemented it properly
which caused that ubifsumount command contains resource leak. It can be
observed by calling simple sequence of commands:

  => ubi part mtd2
  ubi0: attaching mtd2
  ...
  => ubifsmount ubi0
  => ubifsumount
  Unmounting UBIFS volume rootfs!
  => ubi detach
  ubi0 error: ubi_detach_mtd_dev: ubi0 reference count 1, destroy anyway
  ubi0: detaching mtd2
  ubi0: mtd2 is detached

Fix this issue by calling ubi_close_volume() and mutex_unlock() in
directly in ubifs_umount() function before freeing U-Boot's global
ubifs_sb. And remove duplicate calls of these two functions in remaining
places. With this change ubifsumount command does not throw that error
anymore.

  => ubi part rootfs
  ubi0: attaching mtd2
  ...
  => ubifsmount ubi0
  => ubifsumount
  Unmounting UBIFS volume rootfs!
  => ubi detach
  ubi0: detaching mtd2
  ubi0: mtd2 is detached

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 fs/ubifs/super.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index e3a4c0bca270..7677dcc2a140 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1757,6 +1757,8 @@ void ubifs_umount(struct ubifs_info *c)
 	kfree(c->bottom_up_buf);
 	ubifs_debugging_exit(c);
 #ifdef __UBOOT__
+	ubi_close_volume(c->ubi);
+	mutex_unlock(&c->umount_mutex);
 	/* Finally free U-Boot's global copy of superblock */
 	if (ubifs_sb != NULL) {
 		free(ubifs_sb->s_fs_info);
@@ -2058,9 +2060,9 @@ static void ubifs_put_super(struct super_block *sb)
 	ubifs_umount(c);
 #ifndef __UBOOT__
 	bdi_destroy(&c->bdi);
-#endif
 	ubi_close_volume(c->ubi);
 	mutex_unlock(&c->umount_mutex);
+#endif
 }
 #endif
 
@@ -2328,13 +2330,13 @@ static int ubifs_fill_super(struct super_block *sb, void *data, int silent)
 out_umount:
 	ubifs_umount(c);
 out_unlock:
-	mutex_unlock(&c->umount_mutex);
 #ifndef __UBOOT__
+	mutex_unlock(&c->umount_mutex);
 out_bdi:
 	bdi_destroy(&c->bdi);
 out_close:
-#endif
 	ubi_close_volume(c->ubi);
+#endif
 out:
 	return err;
 }
-- 
2.20.1


             reply	other threads:[~2022-05-23 21:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23 21:35 Pali Rohár [this message]
2022-05-30  9:09 ` [PATCH v2] ubifs: Fix reference count leak in ubifsumount Pali Rohár
2022-07-08 16:38   ` Tom Rini

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=20220523213550.14570-1-pali@kernel.org \
    --to=pali@kernel.org \
    --cc=u-boot@lists.denx.de \
    /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.