All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Namjae Jeon" <namjae.jeon@samsung.com>
To: 'Markus Elfring' <Markus.Elfring@web.de>, linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
	"'Christoph Hellwig'" <hch@lst.de>,
	"'Greg Kroah-Hartman'" <gregkh@linuxfoundation.org>,
	"'Sungjong Seo'" <sj1557.seo@samsung.com>,
	"'Valdis Klētnieks'" <valdis.kletnieks@vt.edu>,
	linkinjeon@gmail.com
Subject: RE: [PATCH 02/13] exfat: add super block operations
Date: Mon, 18 Nov 2019 05:01:52 +0000	[thread overview]
Message-ID: <00bb01d59dcd$4b1791b0$e146b510$@samsung.com> (raw)
In-Reply-To: <9e9bac40-109c-3349-24da-532c540638c2@web.de>

> …
> > +++ b/fs/exfat/super.c
> …
> > +static int exfat_show_options(struct seq_file *m, struct dentry *root)
> > +{
> …
> > +	seq_printf(m, ",fmask=%04o", opts->fs_fmask);
> > +	seq_printf(m, ",dmask=%04o", opts->fs_dmask);
> 
> How do you think about to combine these two function calls into a single one?
> 
> 
> > +static int __exfat_fill_super(struct super_block *sb)
> > +{
> …
> > +		exfat_msg(sb, KERN_ERR, "unable to read boot sector");
> > +		ret = -EIO;
> > +		goto out;
> …
> 
> Would you like to simplify this place?
> 
> +		return -EIO;
> 
> 
> …
> > +		exfat_msg(sb, KERN_ERR, "failed to load upcase table");
> > +		goto out;
> 
> Would you like to omit this label?
> 
> +		return ret;
> 
> 
> > +static int exfat_fill_super(struct super_block *sb, struct fs_context *fc)
> > +{
> …
> > +		exfat_msg(sb, KERN_ERR, "failed to recognize exfat type");
> > +		goto failed_mount;
> 
> The local variable “root_inode” contains still a null pointer at this place.
> 
> * Thus I would find a jump target like “reset_s_root” more appropriate.
> 
> * Can the corresponding pointer initialisation be omitted then?
> 
> 
> …
> > +failed_mount:
> > +	if (root_inode)
> > +		iput(root_inode);
> …
> 
> I am informed in the way that this function tolerates the passing
> of null pointers.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/i
> node.c?id=1d4c79ed324ad780cfc3ad38364ba1fd585dd2a8#n1567
> https://protect2.fireeye.com/url?k=34e5568f-697957ef-34e4ddc0-0cc47a31307c-
> 7f9b30869a6ffaa4&u=https://elixir.bootlin.com/linux/v5.4-
> rc7/source/fs/inode.c#L1567
> 
> Thus I suggest to omit the extra pointer check also at this place.
> 
> 
> > +static int __init init_exfat_fs(void)
> > +{
> …
> +	err = exfat_cache_init();
> +	if (err)
> +		goto error;
> 
> Can it be nicer to return directly?
> 
> 
> …
> > +	if (!exfat_inode_cachep)
> > +		goto error;
> 
> Can an other jump target like “shutdown_cache” be more appropriate?
> 
> 
> > +	err = register_filesystem(&exfat_fs_type);
> > +	if (err)
> > +		goto error;
> …
> 
> Can the label “destroy_cache” be more appropriate?
> 
> 
I checked your all points, Will fix them on V2.
Thanks for your review!

> Regards,
> Markus

WARNING: multiple messages have this Message-ID (diff)
From: "Namjae Jeon" <namjae.jeon@samsung.com>
To: "'Markus Elfring'" <Markus.Elfring@web.de>,
	<linux-fsdevel@vger.kernel.org>
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
	"'Christoph Hellwig'" <hch@lst.de>,
	"'Greg Kroah-Hartman'" <gregkh@linuxfoundation.org>,
	"'Sungjong Seo'" <sj1557.seo@samsung.com>,
	"'Valdis Klētnieks'" <valdis.kletnieks@vt.edu>,
	linkinjeon@gmail.com
Subject: RE: [PATCH 02/13] exfat: add super block operations
Date: Mon, 18 Nov 2019 14:01:52 +0900	[thread overview]
Message-ID: <00bb01d59dcd$4b1791b0$e146b510$@samsung.com> (raw)
In-Reply-To: <9e9bac40-109c-3349-24da-532c540638c2@web.de>

> …
> > +++ b/fs/exfat/super.c
> …
> > +static int exfat_show_options(struct seq_file *m, struct dentry *root)
> > +{
> …
> > +	seq_printf(m, ",fmask=%04o", opts->fs_fmask);
> > +	seq_printf(m, ",dmask=%04o", opts->fs_dmask);
> 
> How do you think about to combine these two function calls into a single one?
> 
> 
> > +static int __exfat_fill_super(struct super_block *sb)
> > +{
> …
> > +		exfat_msg(sb, KERN_ERR, "unable to read boot sector");
> > +		ret = -EIO;
> > +		goto out;
> …
> 
> Would you like to simplify this place?
> 
> +		return -EIO;
> 
> 
> …
> > +		exfat_msg(sb, KERN_ERR, "failed to load upcase table");
> > +		goto out;
> 
> Would you like to omit this label?
> 
> +		return ret;
> 
> 
> > +static int exfat_fill_super(struct super_block *sb, struct fs_context *fc)
> > +{
> …
> > +		exfat_msg(sb, KERN_ERR, "failed to recognize exfat type");
> > +		goto failed_mount;
> 
> The local variable “root_inode” contains still a null pointer at this place.
> 
> * Thus I would find a jump target like “reset_s_root” more appropriate.
> 
> * Can the corresponding pointer initialisation be omitted then?
> 
> 
> …
> > +failed_mount:
> > +	if (root_inode)
> > +		iput(root_inode);
> …
> 
> I am informed in the way that this function tolerates the passing
> of null pointers.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/i
> node.c?id=1d4c79ed324ad780cfc3ad38364ba1fd585dd2a8#n1567
> https://protect2.fireeye.com/url?k=34e5568f-697957ef-34e4ddc0-0cc47a31307c-
> 7f9b30869a6ffaa4&u=https://elixir.bootlin.com/linux/v5.4-
> rc7/source/fs/inode.c#L1567
> 
> Thus I suggest to omit the extra pointer check also at this place.
> 
> 
> > +static int __init init_exfat_fs(void)
> > +{
> …
> +	err = exfat_cache_init();
> +	if (err)
> +		goto error;
> 
> Can it be nicer to return directly?
> 
> 
> …
> > +	if (!exfat_inode_cachep)
> > +		goto error;
> 
> Can an other jump target like “shutdown_cache” be more appropriate?
> 
> 
> > +	err = register_filesystem(&exfat_fs_type);
> > +	if (err)
> > +		goto error;
> …
> 
> Can the label “destroy_cache” be more appropriate?
> 
> 
I checked your all points, Will fix them on V2.
Thanks for your review!

> Regards,
> Markus



  reply	other threads:[~2019-11-18  5:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20191113082216epcas1p2e712c23c9524e04be624ccc822b59bf0@epcas1p2.samsung.com>
2019-11-13  8:17 ` [PATCH 00/13] add the latest exfat driver Namjae Jeon
2019-11-13  8:17   ` [PATCH 01/13] exfat: add in-memory and on-disk structures and headers Namjae Jeon
2019-11-17 12:25     ` Markus Elfring
2019-11-17 12:25       ` Markus Elfring
2019-11-18  4:59       ` Namjae Jeon
2019-11-18  4:59         ` Namjae Jeon
2019-11-13  8:17   ` [PATCH 02/13] exfat: add super block operations Namjae Jeon
2019-11-17 13:30     ` Markus Elfring
2019-11-17 13:30       ` Markus Elfring
2019-11-18  5:01       ` Namjae Jeon [this message]
2019-11-18  5:01         ` Namjae Jeon
2019-11-13  8:17   ` [PATCH 03/13] exfat: add inode operations Namjae Jeon
2019-11-17 14:15     ` Markus Elfring
2019-11-17 14:15       ` Markus Elfring
2019-11-18  5:04       ` Namjae Jeon
2019-11-18  5:04         ` Namjae Jeon
2019-11-13  8:17   ` [PATCH 04/13] exfat: add directory operations Namjae Jeon
2019-11-13  8:17   ` [PATCH 05/13] exfat: add file operations Namjae Jeon
2019-11-13  8:17   ` [PATCH 06/13] exfat: add exfat entry operations Namjae Jeon
2019-11-13  8:17   ` [PATCH 07/13] exfat: add bitmap operations Namjae Jeon
2019-11-17 15:01     ` Markus Elfring
2019-11-17 15:01       ` Markus Elfring
2019-11-18  5:05       ` Namjae Jeon
2019-11-18  5:05         ` Namjae Jeon
2019-11-13  8:17   ` [PATCH 08/13] exfat: add exfat cache Namjae Jeon
2019-11-13  8:17   ` [PATCH 09/13] exfat: add misc operations Namjae Jeon
2019-11-13  8:17   ` [PATCH 10/13] exfat: add nls operations Namjae Jeon
2019-11-13  8:17   ` [PATCH 11/13] exfat: add Kconfig and Makefile Namjae Jeon
2019-11-13  8:17   ` [PATCH 12/13] exfat: add exfat in fs/Kconfig and fs/Makefile Namjae Jeon
2019-11-13  8:18   ` [PATCH 13/13] MAINTAINERS: add exfat filesystem Namjae Jeon
2019-11-13 18:48   ` [PATCH 00/13] add the latest exfat driver Valdis Klētnieks
2019-11-13 21:00   ` Eric Sandeen
2019-11-13 21:55     ` Valdis Klētnieks
2019-11-13 21:57       ` Eric Sandeen
2019-11-14  0:41         ` Namjae Jeon

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='00bb01d59dcd$4b1791b0$e146b510$@samsung.com' \
    --to=namjae.jeon@samsung.com \
    --cc=Markus.Elfring@web.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linkinjeon@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sj1557.seo@samsung.com \
    --cc=valdis.kletnieks@vt.edu \
    /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.