* [PATCH v3] romfs: use different way to generate fsid for BLOCK or MTD
@ 2016-12-28 12:36 Coly Li
2017-01-23 14:52 ` Coly Li
0 siblings, 1 reply; 2+ messages in thread
From: Coly Li @ 2016-12-28 12:36 UTC (permalink / raw)
To: linux-fsdevel
Cc: nongli1031, Coly Li, Andrew Morton, Richard Weinberger, linux-mtd
'Commit 8a59f5d25265 ("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.
Signed-off-by: Coly Li <colyli@suse.de>
Reported-by: Nong Li <nongli1031@gmail.com>
Tested-by: Nong Li <nongli1031@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Richard Weinberger <richard.weinberger@gmail.com>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
---
fs/romfs/super.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/fs/romfs/super.c b/fs/romfs/super.c
index d0f8a38..0186fe6 100644
--- a/fs/romfs/super.c
+++ b/fs/romfs/super.c
@@ -74,6 +74,7 @@
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <linux/uaccess.h>
+#include <linux/major.h>
#include "internal.h"
static struct kmem_cache *romfs_inode_cachep;
@@ -416,7 +417,22 @@ 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;
+
+ /* When calling huge_encode_dev(),
+ * use sb->s_bdev->bd_dev when,
+ * - CONFIG_ROMFS_ON_BLOCK defined
+ * use sb->s_dev when,
+ * - CONFIG_ROMFS_ON_BLOCK undefined and
+ * - CONFIG_ROMFS_ON_MTD defined
+ * leave id as 0 when,
+ * - CONFIG_ROMFS_ON_BLOCK undefined and
+ * - CONFIG_ROMFS_ON_MTD undefined
+ */
+ if (sb->s_bdev)
+ id = huge_encode_dev(sb->s_bdev->bd_dev);
+ else if (sb->s_dev)
+ id = huge_encode_dev(sb->s_dev);
buf->f_type = ROMFS_MAGIC;
buf->f_namelen = ROMFS_MAXFN;
@@ -489,6 +505,11 @@ 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);
+#endif
/* read the image superblock and check it */
rsb = kmalloc(512, GFP_KERNEL);
if (!rsb)
--
2.6.6
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH v3] romfs: use different way to generate fsid for BLOCK or MTD
2016-12-28 12:36 [PATCH v3] romfs: use different way to generate fsid for BLOCK or MTD Coly Li
@ 2017-01-23 14:52 ` Coly Li
0 siblings, 0 replies; 2+ messages in thread
From: Coly Li @ 2017-01-23 14:52 UTC (permalink / raw)
To: Coly Li, linux-fsdevel, Andrew Morton
Cc: nongli1031, Richard Weinberger, linux-mtd
Hi Andrew,
This fix is verified by Nong Li, it works well in all three conditions,
- CONFIG_ROMFS_ON_BLOCK defined
- CONFIG_ROMFS_ON_BLOCK undefined and CONFIG_ROMFS_ON_MTD defined
- both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD undefined
Last time the original patch was picked by you, could you please take
care it again this time.
Thanks in advance.
Coly Li
On 2016/12/28 下午8:36, Coly Li wrote:
> 'Commit 8a59f5d25265 ("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.
>
> Signed-off-by: Coly Li <colyli@suse.de>
> Reported-by: Nong Li <nongli1031@gmail.com>
> Tested-by: Nong Li <nongli1031@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Richard Weinberger <richard.weinberger@gmail.com>
> Cc: linux-fsdevel@vger.kernel.org
> Cc: linux-mtd@lists.infradead.org
> ---
> fs/romfs/super.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/fs/romfs/super.c b/fs/romfs/super.c
> index d0f8a38..0186fe6 100644
> --- a/fs/romfs/super.c
> +++ b/fs/romfs/super.c
> @@ -74,6 +74,7 @@
> #include <linux/highmem.h>
> #include <linux/pagemap.h>
> #include <linux/uaccess.h>
> +#include <linux/major.h>
> #include "internal.h"
>
> static struct kmem_cache *romfs_inode_cachep;
> @@ -416,7 +417,22 @@ 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;
> +
> + /* When calling huge_encode_dev(),
> + * use sb->s_bdev->bd_dev when,
> + * - CONFIG_ROMFS_ON_BLOCK defined
> + * use sb->s_dev when,
> + * - CONFIG_ROMFS_ON_BLOCK undefined and
> + * - CONFIG_ROMFS_ON_MTD defined
> + * leave id as 0 when,
> + * - CONFIG_ROMFS_ON_BLOCK undefined and
> + * - CONFIG_ROMFS_ON_MTD undefined
> + */
> + if (sb->s_bdev)
> + id = huge_encode_dev(sb->s_bdev->bd_dev);
> + else if (sb->s_dev)
> + id = huge_encode_dev(sb->s_dev);
>
> buf->f_type = ROMFS_MAGIC;
> buf->f_namelen = ROMFS_MAXFN;
> @@ -489,6 +505,11 @@ 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);
> +#endif
> /* read the image superblock and check it */
> rsb = kmalloc(512, GFP_KERNEL);
> if (!rsb)
>
--
Coly Li
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-01-23 15:34 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-28 12:36 [PATCH v3] romfs: use different way to generate fsid for BLOCK or MTD Coly Li
2017-01-23 14:52 ` Coly Li
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.