Subject: + fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch added to -mm tree To: namjae.jeon@xxxxxxxxxxx,a.sahrawat@xxxxxxxxxxx,hirofumi@xxxxxxxxxxxxxxxxxx From: akpm@xxxxxxxxxxxxxxxxxxxx Date: Mon, 18 Nov 2013 15:22:44 -0800 The patch titled Subject: fat: permit to return phy block number by fibmap in fallocated region has been added to the -mm tree. Its filename is fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Namjae Jeon <namjae.jeon@xxxxxxxxxxx> Subject: fat: permit to return phy block number by fibmap in fallocated region Make the fibmap call the return the proper physical block number for any offset request in the fallocated range. Signed-off-by: Namjae Jeon <namjae.jeon@xxxxxxxxxxx> Signed-off-by: Amit Sahrawat <a.sahrawat@xxxxxxxxxxx> Cc: OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- fs/fat/cache.c | 16 ++++++++++++++-- fs/fat/inode.c | 4 ++-- 2 files changed, 16 insertions(+), 4 deletions(-) diff -puN fs/fat/cache.c~fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region fs/fat/cache.c --- a/fs/fat/cache.c~fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region +++ a/fs/fat/cache.c @@ -312,6 +312,7 @@ int fat_bmap(struct inode *inode, sector const unsigned char blocksize_bits = sb->s_blocksize_bits; sector_t last_block; int cluster, offset; + loff_t i_size = i_size_read(inode); *phys = 0; *mapped_blocks = 0; @@ -323,10 +324,20 @@ int fat_bmap(struct inode *inode, sector return 0; } - last_block = (i_size_read(inode) + (blocksize - 1)) >> blocksize_bits; + last_block = (i_size + (blocksize - 1)) >> blocksize_bits; if (sector >= last_block) { - if (!create) + if (!create) { + /* + * to map cluster in case of read request + * for a block in fallocated region + */ + if (MSDOS_I(inode)->i_disksize > + round_up(i_size, sb->s_blocksize)) { + goto out_map_cluster; + } + return 0; + } /* * Both ->mmu_private and ->i_disksize can access @@ -339,6 +350,7 @@ int fat_bmap(struct inode *inode, sector return 0; } +out_map_cluster: cluster = sector >> (sbi->cluster_bits - sb->s_blocksize_bits); offset = sector & (sbi->sec_per_clus - 1); cluster = fat_bmap_cluster(inode, cluster); diff -puN fs/fat/inode.c~fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region fs/fat/inode.c --- a/fs/fat/inode.c~fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region +++ a/fs/fat/inode.c @@ -245,9 +245,9 @@ static sector_t _fat_bmap(struct address sector_t blocknr; /* fat_get_cluster() assumes the requested blocknr isn't truncated. */ - down_read(&MSDOS_I(mapping->host)->truncate_lock); + mutex_lock(&mapping->host->i_mutex); blocknr = generic_block_bmap(mapping, block, fat_get_block); - up_read(&MSDOS_I(mapping->host)->truncate_lock); + mutex_unlock(&mapping->host->i_mutex); return blocknr; } _ Patches currently in -mm which might be from namjae.jeon@xxxxxxxxxxx are fat-add-i_disksize-to-represent-uninitialized-size.patch fat-add-fat_fallocate-operation.patch fat-zero-out-seek-range-on-_fat_get_block.patch fat-fallback-to-buffered-write-in-case-of-fallocatded-region-on-direct-io.patch fat-permit-to-return-phy-block-number-by-fibmap-in-fallocated-region.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html