On 2016/12/28 下午5:44, Richard Weinberger wrote:
> CC'ing MTD
>
> On Wed, Dec 28, 2016 at 9:53 AM, Coly Li <colyli@xxxxxxx> wrote:
>> static struct kmem_cache *romfs_inode_cachep;
>> @@ -416,8 +417,14 @@ static void romfs_destroy_inode(struct inode *inode)
>> static int romfs_statfs(struct dentry *dentry, struct kstatfs *buf)
>> {
>> struct super_block *sb = dentry->d_sb;
>> - u64 id = huge_encode_dev(sb->s_bdev->bd_dev);
>> + u64 id = 0;
>>
>> +#ifdef CONFIG_ROMFS_ON_BLOCK
>> + id = huge_encode_dev(sb->s_bdev->bd_dev);
>> +#endif
>> +#ifdef CONFIG_ROMFS_ON_MTD
>> + id = huge_encode_dev(sb->s_dev);
>> +#endif
>
> How is this supposed to work with CONFIG_ROMFS_BACKED_BY_BOTH=y?
Aha! Thanks for telling me this config option.
The purpose of f_fsid is to unify a file system volume, if
CONFIG_ROMFS_BACKED_BY_BOTH=y, it can firstly try sb->s_bdev->bd_dev. If
sb->s_bdev is NULL, then try sb->s_dev. If both failed, then f_fsid will
be 0.
>
>> buf->f_type = ROMFS_MAGIC;
>> buf->f_namelen = ROMFS_MAXFN;
>> buf->f_bsize = ROMBSIZE;
>> @@ -489,6 +496,13 @@ static int romfs_fill_super(struct super_block *sb, void *data, int silent)
>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>> sb->s_op = &romfs_super_ops;
>>
>> +#ifdef CONFIG_ROMFS_ON_MTD
>> + /* Use same dev ID from the underlying mtdblock device */
>> + if (sb->s_mtd)
>> + sb->s_dev = MKDEV(MTD_BLOCK_MAJOR, sb->s_mtd->index);
>> + else
>> + sb->s_dev = MKDEV(MTD_BLOCK_MAJOR, 0);
>
> Hmm, when there is no MTD, s_dev is still equal to mtd0, since mtd0 is
> ->index of
> value 0. This seems fishy to me.
You are right, if both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD are
defined, here is buggy.
Thanks for your review, I will send out another version.
Coly
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
