[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200108172135.GC13388@lst.de>
Date: Wed, 8 Jan 2020 18:21:35 +0100
From: Christoph Hellwig <hch@....de>
To: Namjae Jeon <namjae.jeon@...sung.com>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
gregkh@...uxfoundation.org, valdis.kletnieks@...edu, hch@....de,
sj1557.seo@...sung.com, linkinjeon@...il.com, pali.rohar@...il.com
Subject: Re: [PATCH v9 02/13] exfat: add super block operations
Looks good, modulo a few nitpicks below:
Reviewed-by: Christoph Hellwig <hch@....de>
On Thu, Jan 02, 2020 at 04:20:25PM +0800, Namjae Jeon wrote:
> +static int exfat_statfs(struct dentry *dentry, struct kstatfs *buf)
> +{
> + struct super_block *sb = dentry->d_sb;
> + struct exfat_sb_info *sbi = EXFAT_SB(sb);
> + unsigned long long id = huge_encode_dev(sb->s_bdev->bd_dev);
> + if (sbi->used_clusters == ~0u) {
Various other places use UINT_MAX here instead. Maybe it makes sense
to add a EXFAT_CLUSTERS_UNTRACKED or similar define and use that in all
places?
> + if ((new_flag == VOL_DIRTY) && (!buffer_dirty(sbi->pbr_bh)))
No need for both sets of inner braces.
> +static bool is_exfat(struct pbr *pbr)
> +{
> + int i = MUST_BE_ZERO_LEN;
> +
> + do {
> + if (pbr->bpb.f64.res_zero[i - 1])
> + break;
> + } while (--i);
> + return i ? false : true;
> +}
I find the MUST_BE_ZERO_LEN a little weird here. Maybe that should
be something like PBP64_RESERVED_LEN?
Also I think this could be simplified by just using memchr_inv in the
caller
if (memchr_inv(pbr->bpb.f64.res_zero, 0,
sizeof(pbr->bpb.f64.res_zero)))
ret = -EINVAL;
goto free_bh;
}
> + /* set maximum file size for exFAT */
> + sb->s_maxbytes = 0x7fffffffffffffffLL;
That this is setting the max size is pretty obvious. Maybe the comment
should be updated to mention how this max file size is calculated?
Powered by blists - more mailing lists