From: "Pali Rohár" <pali@kernel.org>
To: u-boot@lists.denx.de
Subject: [PATCH v2] ubifs: Fix reference count leak in ubifsumount
Date: Mon, 30 May 2022 11:09:11 +0200 [thread overview]
Message-ID: <20220530090911.28169-1-pali@kernel.org> (raw)
In-Reply-To: <20220523213550.14570-1-pali@kernel.org>
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. Note that when ubifs_umount() is not called then during error
handling is still needed to call ubi_close_volume() and mutex_unlock.
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>
---
Changes in v2:
* Fix error handling in ubifs_fill_super()
---
fs/ubifs/super.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index e3a4c0bca270..034c41a70356 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
@@ -2327,6 +2329,9 @@ static int ubifs_fill_super(struct super_block *sb, void *data, int silent)
out_umount:
ubifs_umount(c);
+#ifdef __UBOOT__
+ goto out;
+#endif
out_unlock:
mutex_unlock(&c->umount_mutex);
#ifndef __UBOOT__
--
2.20.1
next prev parent reply other threads:[~2022-05-30 9:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-23 21:35 [PATCH] ubifs: Fix reference count leak in ubifsumount Pali Rohár
2022-05-30 9:09 ` Pali Rohár [this message]
2022-07-08 16:38 ` [PATCH v2] " 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=20220530090911.28169-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.