From: Aditya Garg <gargaditya08@live.com>
To: "willy@infradead.org" <willy@infradead.org>,
"ira.weiny@intel.com" <ira.weiny@intel.com>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"songmuchun@bytedance.com" <songmuchun@bytedance.com>,
"slava@dubeyko.com" <slava@dubeyko.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [PATCH] hfsplus: Add module parameter to enable force writes
Date: Fri, 2 Dec 2022 06:01:16 +0000 [thread overview]
Message-ID: <53821C76-DAFE-4505-9EC8-BE4ACBEA9DD9@live.com> (raw)
From: Aditya Garg <gargaditya08@live.com>
This patch enables users to permanently enable writes of HFS+ locked
and/or journaled volumes using a module parameter.
Why module parameter?
Reason being, its not convenient to manually mount the volume with force
everytime. There are use cases which are fine with force enabling writes
on journaled volumes. I've seen many on various online forums and I am one
of them as well.
Isn't it risky?
Yes obviously it is, as the driver itself warns users for the same. But
any user using the parameter obviously shall be well aware of the risks
involved. To be honest, I've been writing on a 100Gb journaled volume for
a few days, including both large and small files, and haven't faced any
corruption yet.
Signed-off-by: Aditya Garg <gargaditya08@live.com>
---
fs/hfsplus/super.c | 46 ++++++++++++++++++++++++++++++++++++----------
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c
index 122ed89eb..2367a2407 100644
--- a/fs/hfsplus/super.c
+++ b/fs/hfsplus/super.c
@@ -24,6 +24,16 @@ static void hfsplus_free_inode(struct inode *inode);
#include "hfsplus_fs.h"
#include "xattr.h"
+static unsigned int force_journaled_rw;
+module_param(force_journaled_rw, uint, 0644);
+MODULE_PARM_DESC(force_journaled_rw, "Force enable writes on Journaled HFS+ volumes. "
+ "([0] = disabled, 1 = enabled)");
+
+static unsigned int force_locked_rw;
+module_param(force_locked_rw, uint, 0644);
+MODULE_PARM_DESC(force_locked_rw, "Force enable writes on locked HFS+ volumes. "
+ "([0] = disabled, 1 = enabled)");
+
static int hfsplus_system_read_inode(struct inode *inode)
{
struct hfsplus_vh *vhdr = HFSPLUS_SB(inode->i_sb)->s_vhdr;
@@ -346,14 +356,22 @@ static int hfsplus_remount(struct super_block *sb, int *flags, char *data)
/* nothing */
} else if (vhdr->attributes &
cpu_to_be32(HFSPLUS_VOL_SOFTLOCK)) {
- pr_warn("filesystem is marked locked, leaving read-only.\n");
- sb->s_flags |= SB_RDONLY;
- *flags |= SB_RDONLY;
+ if (force_locked_rw) {
+ pr_warn("filesystem is marked locked, but writes have been force enabled.\n");
+ } else {
+ pr_warn("filesystem is marked locked, leaving read-only.\n");
+ sb->s_flags |= SB_RDONLY;
+ *flags |= SB_RDONLY;
+ }
} else if (vhdr->attributes &
cpu_to_be32(HFSPLUS_VOL_JOURNALED)) {
- pr_warn("filesystem is marked journaled, leaving read-only.\n");
- sb->s_flags |= SB_RDONLY;
- *flags |= SB_RDONLY;
+ if (force_journaled_rw) {
+ pr_warn("filesystem is marked journaled, but writes have been force enabled.\n");
+ } else {
+ pr_warn("filesystem is marked journaled, leaving read-only.\n");
+ sb->s_flags |= SB_RDONLY;
+ *flags |= SB_RDONLY;
+ }
}
}
return 0;
@@ -459,12 +477,20 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent)
} else if (test_and_clear_bit(HFSPLUS_SB_FORCE, &sbi->flags)) {
/* nothing */
} else if (vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_SOFTLOCK)) {
- pr_warn("Filesystem is marked locked, mounting read-only.\n");
- sb->s_flags |= SB_RDONLY;
+ if (force_locked_rw) {
+ pr_warn("Filesystem is marked locked, but writes have been force enabled.\n");
+ } else {
+ pr_warn("Filesystem is marked locked, mounting read-only.\n");
+ sb->s_flags |= SB_RDONLY;
+ }
} else if ((vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_JOURNALED)) &&
!sb_rdonly(sb)) {
- pr_warn("write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only.\n");
- sb->s_flags |= SB_RDONLY;
+ if (force_journaled_rw) {
+ pr_warn("write access to a journaled filesystem is not supported, but has been force enabled.\n");
+ } else {
+ pr_warn("write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only.\n");
+ sb->s_flags |= SB_RDONLY;
+ }
}
err = -EINVAL;
--
2.38.1
next reply other threads:[~2022-12-02 6:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 6:01 Aditya Garg [this message]
2022-12-02 20:38 ` Viacheslav Dubeyko
2022-12-02 20:53 ` Andrew Morton
2022-12-02 21:01 ` Matthew Wilcox
2022-12-02 21:10 ` Andrew Morton
2022-12-03 6:22 ` Aditya Garg
2022-12-04 8:07 ` Christoph Hellwig
2022-12-04 11:01 ` Aditya Garg
2022-12-06 8:52 ` Christoph Hellwig
2022-12-03 7:11 ` [PATCH v2] " Aditya Garg
2022-12-04 1:05 ` kernel test robot
2022-12-04 6:43 ` Aditya Garg
2022-12-06 15:17 ` Matthew Wilcox
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=53821C76-DAFE-4505-9EC8-BE4ACBEA9DD9@live.com \
--to=gargaditya08@live.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=ira.weiny@intel.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=slava@dubeyko.com \
--cc=songmuchun@bytedance.com \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®