• Coly Li's avatar
    romfs: use different way to generate fsid for BLOCK or MTD · f598f82e
    Coly Li authored
    Commit 8a59f5d2 ("fs/romfs: return f_fsid for statfs(2)") generates
    a 64bit id from sb->s_bdev->bd_dev.  This is only correct when romfs is
    defined with CONFIG_ROMFS_ON_BLOCK.  If romfs is only defined with
    CONFIG_ROMFS_ON_MTD, sb->s_bdev is NULL, referencing sb->s_bdev->bd_dev
    will triger an oops.
    
    Richard Weinberger points out that when CONFIG_ROMFS_BACKED_BY_BOTH=y,
    both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD are defined.
    Therefore when calling huge_encode_dev() to generate a 64bit id, I use
    the follow order to choose parameter,
    
    - CONFIG_ROMFS_ON_BLOCK defined
      use sb->s_bdev->bd_dev
    - CONFIG_ROMFS_ON_BLOCK undefined and CONFIG_ROMFS_ON_MTD defined
      use sb->s_dev when,
    - both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD undefined
      leave id as 0
    
    When CONFIG_ROMFS_ON_MTD is defined and sb->s_mtd is not NULL, sb->s_dev
    is set to a device ID generated by MTD_BLOCK_MAJOR and mtd index,
    otherwise sb->s_dev is 0.
    
    This is a try-best effort to generate a uniq file system ID, if all the
    above conditions are not meet, f_fsid of this romfs instance will be 0.
    Generally only one romfs can be built on single MTD block device, this
    method is enough to identify multiple romfs instances in a computer.
    
    Link: http://lkml.kernel.org/r/1482928596-115155-1-git-send-email-colyli@suse.deSigned-off-by: default avatarColy Li <colyli@suse.de>
    Reported-by: default avatarNong Li <nongli1031@gmail.com>
    Tested-by: default avatarNong Li <nongli1031@gmail.com>
    Cc: Richard Weinberger <richard.weinberger@gmail.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    f598f82e
super.c 15.5 KB