[RFC] vfs/inode: For none-block-based filesystems default to sb->s_bdi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In alloc_inode (inode_init_always) in the case that sb->s_bdev
is NULL. Should we not use sb->s_bdi as the default
mapping->backing_dev_info?

This fixes my none-block-based filesystem recent WARN_ON
at fs/fs-writeback.c:87 inode_to_bdi()

If not done here I'll need to do this in 5 different cases
in FS code. (OK the code could enjoy some re-factoring).

It does look logical the question is how many FSs will now
get broken?

Signed-off-by: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
---
 fs/inode.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index 8646433..200314f 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -181,6 +181,8 @@ int inode_init_always(struct super_block *sb, struct inode *inode)
 
 		bdi = sb->s_bdev->bd_inode->i_mapping->backing_dev_info;
 		mapping->backing_dev_info = bdi;
+	} else {
+		mapping->backing_dev_info = sb->s_bdi;
 	}
 	inode->i_private = NULL;
 	inode->i_mapping = mapping;
-- 
1.7.2

--
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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux