driverdev-devel.linuxdriverproject.org archive mirror
 help / color / mirror / Atom feed
From: hsiangkao@aol.com (Gao Xiang)
Subject: [PATCH v2 03/24] erofs: add super block operations
Date: Sun, 21 Jul 2019 11:08:42 +0800	[thread overview]
Message-ID: <161cffc4-1d61-5dc6-45df-f1779ef03b0f@aol.com> (raw)
In-Reply-To: <20190720224955.GD17978@ZenIV.linux.org.uk>

Hi Al,

On 2019/7/21 ????6:49, Al Viro wrote:
> On Thu, Jul 11, 2019@10:57:34PM +0800, Gao Xiang wrote:
>> This commit adds erofs super block operations, including (u)mount,
>> remount_fs, show_options, statfs, in addition to some private
>> icache management functions.
> Could you explain what's the point of this
>
>> +	/* save the device name to sbi */
>> +	sbi->dev_name = __getname();
>> +	if (!sbi->dev_name) {
>> +		err = -ENOMEM;
>> +		goto err_devname;
>> +	}
>> +
>> +	snprintf(sbi->dev_name, PATH_MAX, "%s", dev_name);
>> +	sbi->dev_name[PATH_MAX - 1] = '\0';
> ... and this?

Thanks for your kindly reply...

Yes, I remember the above code you already mentioned months ago... The
detail is that

It is for debugging use as you said below, mainly for our internal
testers whose jobs are
to read kmsg logs and catch kernel problems. sb->s_id (device number)
maybe not
straight-forward for them compared with dev_name...

The initial purpose of erofs_mount_private was to passing multi private
data from erofs_mount
to erofs_read_super, which was written before fs_contest was introduced.

I agree with you, it seems better to just use s_id in community and
delete erofs_mount_private stuffs...
Yet I don't look into how to use new fs_context, could I keep using
legacy mount interface and fix them all?


>
>> +struct erofs_mount_private {
>> +	const char *dev_name;
>> +	char *options;
>> +};
>> +
>> +/* support mount_bdev() with options */
>> +static int erofs_fill_super(struct super_block *sb,
>> +			    void *_priv, int silent)
>> +{
>> +	struct erofs_mount_private *priv = _priv;
>> +
>> +	return erofs_read_super(sb, priv->dev_name,
>> +		priv->options, silent);
>> +}
>> +
>> +static struct dentry *erofs_mount(
>> +	struct file_system_type *fs_type, int flags,
>> +	const char *dev_name, void *data)
>> +{
>> +	struct erofs_mount_private priv = {
>> +		.dev_name = dev_name,
>> +		.options = data
>> +	};
>> +
>> +	return mount_bdev(fs_type, flags, dev_name,
>> +		&priv, erofs_fill_super);
>> +}
> AFAICS, the only use of sbi->dev_name is debugging printks and
> all of those have sb->s_id available, with device name stored
> in there.  Which makes the whole thing bloody weird - what's
> wrong with simply passing data to mount_bdev (instead of
> &priv), folding erofs_read_super() into erofs_fill_super(),
> replacing sbi->dev_name with sb->s_id and killing sbi->dev_name,
> along with the associated allocation, freeing, handling of
> allocation failure, etc.?


OK, make sense. I will do...


>
> For drivers/staging location that would be (compile-tested only)
> the diff below.  I suspect that you could simplify fill_super
> a bit further if you added ->kill_sb() along the lines of
>
> 	sbi = EROFS(sb);
> #ifdef EROFS_FS_HAS_MANAGED_CACHE
> 	if (sbi && !sb->s_root)
> 		iput(sbi->managed_cache);
> #endif
> 	kill_block_super(sb);
> 	kfree(sbi);
> and took freeing sbi out of your ->put_super().  Then fill_super()
> would simply return -E... on all failure exits, leaving all cleanup
> to ->kill_sb().  E.g. initialization of the same ->managed_cache
> would become
> #ifdef EROFS_FS_HAS_MANAGED_CACHE
> 	inode = erofs_init_managed_cache(sb);
>         if (IS_ERR(inode))
> 		return PTR_ERR(inode);
> 	sbi->managed_cache = inode;
> #endif
> etc.  Matter of taste, but IME if destructor parallels the cleanups on failure
> exits in constructor it often makes sense to make use of that and kill the
> duplication...  Anyway, that's a separate store; sbi->dev_name is a lot more
> obvious one.


I guess if I don't misunderstand, that is another suggestion -- in
short, leave all destructors to .kill_sb() and
cleanup fill_super(). I think it makes sense as well, though the reason
why the initial erofs code was is that
I just refer other filesystems such as ext4 and f2fs which handle
failure in fill_super() constructor as well.
Anyway, your suggestion is a good idea (it's more cleaner), I will play
with it.

I will kill dev_name in patch v3 at least, and try to clean up all
failure exits as you mentioned.

Thanks for your suggestions... Let me resend v3 later :)

Thanks,
Gao Xiang


>
>
> diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
> index 382258fc124d..16bab07e69d8 100644
> --- a/drivers/staging/erofs/internal.h
> +++ b/drivers/staging/erofs/internal.h
> @@ -117,8 +117,6 @@ struct erofs_sb_info {
>  	u8 volume_name[16];             /* volume name */
>  	u32 requirements;
>  
> -	char *dev_name;
> -
>  	unsigned int mount_opt;
>  	unsigned int shrinker_run_no;
>  
> diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
> index cadbcc11702a..a6ee69d0ce45 100644
> --- a/drivers/staging/erofs/super.c
> +++ b/drivers/staging/erofs/super.c
> @@ -367,15 +367,14 @@ static struct inode *erofs_init_managed_cache(struct super_block *sb)
>  
>  #endif
>  
> -static int erofs_read_super(struct super_block *sb,
> -			    const char *dev_name,
> +static int erofs_fill_super(struct super_block *sb,
>  			    void *data, int silent)
>  {
>  	struct inode *inode;
>  	struct erofs_sb_info *sbi;
>  	int err = -EINVAL;
>  
> -	infoln("read_super, device -> %s", dev_name);
> +	infoln("read_super, device -> %s", sb->s_id);
>  	infoln("options -> %s", (char *)data);
>  
>  	if (unlikely(!sb_set_blocksize(sb, EROFS_BLKSIZ))) {
> @@ -453,20 +452,10 @@ static int erofs_read_super(struct super_block *sb,
>  		goto err_iget;
>  	}
>  
> -	/* save the device name to sbi */
> -	sbi->dev_name = __getname();
> -	if (!sbi->dev_name) {
> -		err = -ENOMEM;
> -		goto err_devname;
> -	}
> -
> -	snprintf(sbi->dev_name, PATH_MAX, "%s", dev_name);
> -	sbi->dev_name[PATH_MAX - 1] = '\0';
> -
>  	erofs_register_super(sb);
>  
>  	if (!silent)
> -		infoln("mounted on %s with opts: %s.", dev_name,
> +		infoln("mounted on %s with opts: %s.", sb->s_id,
>  		       (char *)data);
>  	return 0;
>  	/*
> @@ -474,9 +463,6 @@ static int erofs_read_super(struct super_block *sb,
>  	 * the following name convention, thus new features
>  	 * can be integrated easily without renaming labels.
>  	 */
> -err_devname:
> -	dput(sb->s_root);
> -	sb->s_root = NULL;
>  err_iget:
>  #ifdef EROFS_FS_HAS_MANAGED_CACHE
>  	iput(sbi->managed_cache);
> @@ -504,8 +490,7 @@ static void erofs_put_super(struct super_block *sb)
>  
>  	WARN_ON(sb->s_magic != EROFS_SUPER_MAGIC);
>  
> -	infoln("unmounted for %s", sbi->dev_name);
> -	__putname(sbi->dev_name);
> +	infoln("unmounted for %s", sb->s_id);
>  
>  #ifdef EROFS_FS_HAS_MANAGED_CACHE
>  	iput(sbi->managed_cache);
> @@ -525,33 +510,12 @@ static void erofs_put_super(struct super_block *sb)
>  	sb->s_fs_info = NULL;
>  }
>  
> -
> -struct erofs_mount_private {
> -	const char *dev_name;
> -	char *options;
> -};
> -
> -/* support mount_bdev() with options */
> -static int erofs_fill_super(struct super_block *sb,
> -			    void *_priv, int silent)
> -{
> -	struct erofs_mount_private *priv = _priv;
> -
> -	return erofs_read_super(sb, priv->dev_name,
> -		priv->options, silent);
> -}
> -
>  static struct dentry *erofs_mount(
>  	struct file_system_type *fs_type, int flags,
>  	const char *dev_name, void *data)
>  {
> -	struct erofs_mount_private priv = {
> -		.dev_name = dev_name,
> -		.options = data
> -	};
> -
>  	return mount_bdev(fs_type, flags, dev_name,
> -		&priv, erofs_fill_super);
> +		data, erofs_fill_super);
>  }
>  
>  static void erofs_kill_sb(struct super_block *sb)

  reply	other threads:[~2019-07-21  3:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-11 14:57 [PATCH v2 00/24] erofs: promote erofs from staging Gao Xiang
2019-07-11 14:57 ` [PATCH v2 01/24] erofs: add on-disk layout Gao Xiang
2019-07-11 14:57 ` [PATCH v2 02/24] erofs: add erofs in-memory stuffs Gao Xiang
2019-07-11 14:57 ` [PATCH v2 03/24] erofs: add super block operations Gao Xiang
2019-07-20 22:49   ` Al Viro
2019-07-21  3:08     ` Gao Xiang [this message]
2019-07-21  4:05       ` Al Viro
2019-07-21  4:12         ` Gao Xiang
2019-07-21 18:05           ` Gao Xiang
2019-07-11 14:57 ` [PATCH v2 04/24] erofs: add raw address_space operations Gao Xiang
2019-07-11 14:57 ` [PATCH v2 05/24] erofs: add inode operations Gao Xiang
2019-07-11 14:57 ` [PATCH v2 06/24] erofs: support special inode Gao Xiang
2019-07-11 14:57 ` [PATCH v2 07/24] erofs: add directory operations Gao Xiang
2019-07-11 14:57 ` [PATCH v2 08/24] erofs: add namei functions Gao Xiang
2019-07-11 14:57 ` [PATCH v2 09/24] erofs: support tracepoint Gao Xiang
2019-07-11 14:57 ` [PATCH v2 10/24] erofs: update Kconfig and Makefile Gao Xiang
2019-07-11 14:57 ` [PATCH v2 11/24] erofs: introduce xattr & posixacl support Gao Xiang
2019-07-11 14:57 ` [PATCH v2 12/24] erofs: introduce tagged pointer Gao Xiang
2019-07-11 14:57 ` [PATCH v2 13/24] erofs: add compression indexes support Gao Xiang
2019-07-11 14:57 ` [PATCH v2 14/24] erofs: introduce superblock registration Gao Xiang
2019-07-11 14:57 ` [PATCH v2 15/24] erofs: introduce erofs shrinker Gao Xiang
2019-07-11 14:57 ` [PATCH v2 16/24] erofs: introduce workstation for decompression Gao Xiang
2019-07-11 14:57 ` [PATCH v2 17/24] erofs: introduce per-CPU buffers implementation Gao Xiang
2019-07-11 14:57 ` [PATCH v2 18/24] erofs: introduce pagevec for decompression subsystem Gao Xiang
2019-07-11 14:57 ` [PATCH v2 19/24] erofs: add erofs_allocpage() Gao Xiang
2019-07-11 14:57 ` [PATCH v2 20/24] erofs: introduce generic decompression backend Gao Xiang
2019-07-11 14:57 ` [PATCH v2 21/24] erofs: introduce LZ4 decompression inplace Gao Xiang
2019-07-11 14:57 ` [PATCH v2 22/24] erofs: introduce the decompression frontend Gao Xiang
2019-07-11 14:57 ` [PATCH v2 23/24] erofs: introduce cached decompression Gao Xiang
2019-07-11 14:57 ` [PATCH v2 24/24] erofs: add document Gao Xiang
2019-07-14 10:49 ` [PATCH v2 00/24] erofs: promote erofs from staging Pavel Machek
2019-07-14 20:17   ` Gao Xiang
2019-07-15  7:56     ` Pavel Machek
2019-07-15  8:37       ` Gao Xiang

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=161cffc4-1d61-5dc6-45df-f1779ef03b0f@aol.com \
    --to=hsiangkao@aol.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).