Re: [PATCH v2 5/5] fat: permit to return phy block number by fibmapin fallocated region

From: Namjae Jeon
Date: Thu Dec 05 2013 - 09:20:24 EST


2013/12/1, OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>:
> Namjae Jeon <linkinjeon@xxxxxxxxx> writes:
>
>> diff --git a/fs/fat/cache.c b/fs/fat/cache.c
>> index c56bd7e..7777822 100644
>> --- a/fs/fat/cache.c
>> +++ b/fs/fat/cache.c
>> @@ -312,6 +312,7 @@ int fat_bmap(struct inode *inode, sector_t sector,
>> sector_t *phys,
>> 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_t sector,
>> sector_t *phys,
>> 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;
>> + }
>
> Said on another reply though, we will have to add new flag for
> this. Because normal read get_block() operation should not return
> mapping beyond ->i_size.
Okay.
>
>> /* 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;
>> }
>
> ->i_mutex doesn't work for swapfile.
Sorry, Actually, I don't understand why it is related with swapfile.
Could you elaborate more ?

Thanks.
> --
> OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/