hfsplus: Add module parameter to enable force writes

  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(-)
  

> On Dec 1, 2022, at 10:01 PM, Aditya Garg <gargaditya08@live.com> wrote:
> 
> 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.
> 

If you created HFS+ volume under Linux, then you never have journal
and problem of journal replay (even if you created journaled volume).
So, I see the only one case when you have journal with transactions.
You are using HFS+ volume in Linux and Mac OS X. It means that
Mac OS X can create transactions in the journal and Linux needs
to manage it somehow.

Even if you don’t see any corruptions after such short testing, then
it doesn’t mean that you are safe. The key trouble that you can
silently lose the data because some metadata state could sit
in the journal and no replay operation has happened. Yes, you can
ignore the transactions in the journal and continue to store data and
modify metadata. But if journal still contain valid transactions, then
mount operation under Mac OS X will replay journal. And it sounds
that journal replay under Mac OS X can corrupt metadata and data
state that was modified/created under Linux.

So, I believe that your suggestion is slightly dangerous because
people loves to make mistakes and really hates to lose data.

Thanks,
Slava. 

> 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
>
  

On Fri, 2 Dec 2022 06:01:16 +0000 Aditya Garg <gargaditya08@live.com> wrote:

> 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.
> 

Presumably anyone who enables this knows the risk, and if it's a
convenience, why not.

Documentation/filesystems/hfsplus.rst would be a good place to document
this module parameter please.

> --- a/fs/hfsplus/super.c
> +++ b/fs/hfsplus/super.c
> @@ -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;
> +		}

All these super long lines are an eyesore.  How about

			pr_warn("write access to a journaled filesystem is "
				"not supported, but has been force enabled.\n");
  

On Fri, Dec 02, 2022 at 12:53:44PM -0800, Andrew Morton wrote:
> > +		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;
> > +		}
> 
> All these super long lines are an eyesore.  How about
> 
> 			pr_warn("write access to a journaled filesystem is "
> 				"not supported, but has been force enabled.\n");

Linus has asked us to not do that because it makes it hard to grep.
  

On Fri, 2 Dec 2022 21:01:44 +0000 Matthew Wilcox <willy@infradead.org> wrote:

> On Fri, Dec 02, 2022 at 12:53:44PM -0800, Andrew Morton wrote:
> > > +		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;
> > > +		}
> > 
> > All these super long lines are an eyesore.  How about
> > 
> > 			pr_warn("write access to a journaled filesystem is "
> > 				"not supported, but has been force enabled.\n");
> 
> Linus has asked us to not do that because it makes it hard to grep.

Yup.  But as with everything, there are tradeoffs.  These messages are
so messy to read and reading code is more common than grepping for
error messages.  Just grep the first 20-30 characters...
  

> Presumably anyone who enables this knows the risk, and if it's a
> convenience, why not.
> 
> Documentation/filesystems/hfsplus.rst would be a good place to document
> this module parameter please.

I’ll add it to the v2

> All these super long lines are an eyesore.  How about
> 
> pr_warn("write access to a journaled filesystem is "
> "not supported, but has been force enabled.\n");

I’ll fix this, but you'll find a lot of eyesore lines in this driver, which I guess someone would have to fix then.
  

NAK.  Global module options overriding mount options don't make sense.
If you mount so much write yourself a script, or add the option to the
configuration of the automounting tool of your choice.
  

> On 04-Dec-2022, at 1:37 PM, Christoph Hellwig <hch@lst.de> wrote:
> 
> NAK.  Global module options overriding mount options don't make sense.
> If you mount so much write yourself a script, or add the option to the
> configuration of the automounting tool of your choice.

Hi Christoph
My bad I wasn't aware udisks2 now supports custom configuration. I just came to know about this and thus this patch of mine indeed does not make any sense now.

Although, if you think its worth it, the following improvements can be made :-

1. There is no logging showing that writes have been force enabled. We could add that.
2. We could have separate mount options for journaled and locked volumes (although I dunno in what case we get locked volumes).
  

On Sun, Dec 04, 2022 at 11:01:49AM +0000, Aditya Garg wrote:
> Although, if you think its worth it, the following improvements can be made :-
> 
> 1. There is no logging showing that writes have been force enabled. We could add that.

I think this would be very useful.

> 2. We could have separate mount options for journaled and locked volumes (although I dunno in what case we get locked volumes).

We can't really retire the existing option, but if for your use case
you'd prefer to only allow one of them and want to not write to the
other case feel free to submit a patch to add that option.