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

[Namjae Jeon]

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/