linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: liuxue <liuxueliu.liu@huawei.com>,
	'Yunlei He' <heyunlei@huawei.com>,
	linux-f2fs-devel@lists.sourceforge.net, jaegeuk@kernel.org
Subject: Re: [PATCH] f2fs: add a max block count for f2fs_map_blocks
Date: Sat, 26 Dec 2015 21:21:00 +0800	[thread overview]
Message-ID: <567E943C.6050905@kernel.org> (raw)
In-Reply-To: <567D17B7.7060308@huawei.com>

Hi,

On 12/25/15 6:17 PM, liuxue wrote:
> On 2015/12/25 17:25, Chao Yu wrote:
>> Hi,
>>
>>> -----Original Message-----
>>> From: Yunlei He [mailto:heyunlei@huawei.com]
>>> Sent: Friday, December 25, 2015 4:48 PM
>>> To: linux-f2fs-devel@lists.sourceforge.net; jaegeuk@kernel.org; chao2.yu@samsung.com
>>> Cc: bintian.wang@huawei.com; Yunlei He; Xue Liu
>>> Subject: [PATCH] f2fs: add a max block count for f2fs_map_blocks
>>>
>>> This patch adds a max block count for f2fs_map_blocks
>>
>> Maximum file size should be limited by sb->s_maxbytes which was inited
>> in max_file_size(), so logical block index should not exceed the value
>> calculated with maxbytes, why would we limit logical block index with
>> another value?
>>
>> Thanks,
>>
> 
> Hi,
> Trinity test program will send a block number as parameter into ioctl_fibmap, which will be used in
> get_node_path(), when the block number large than f2fs max blocks, it will trigger kernel bug.
> So we judge the block number in f2fs_map_blocks(), which reference ext4:

Thanks for the explanation, and this makes sense to me, it's better to add above
message in commit log.

> 
> file: fs/ext4/inode.c
> function: ext4_map_blocks()
> 
>      /* We can handle the block number less than EXT_MAX_BLOCKS */
>      if (unlikely(map->m_lblk >= EXT_MAX_BLOCKS))
>          return -EFSCORRUPTED;
> 
> 
>>>
>>> Signed-off-by: Yunlei He <heyunlei@huawei.com>
>>> Signed-off-by: Xue Liu <liuxueliu.liu@huawei.com>
>>> ---
>>>   fs/f2fs/data.c | 4 ++++
>>>   fs/f2fs/f2fs.h | 3 +++
>>>   2 files changed, 7 insertions(+)
>>>
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index e34b1bd..2a16c867 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -578,6 +578,10 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map,

As you mentioned, this bug will only be triggered in bmap, so how about checking
upper boundary in get_data_block_bmap? Since we could remain bug_on in
get_node_path for other call paths to check whether this is a bug of VFS or not.

>>>   	map->m_len = 0;
>>>   	map->m_flags = 0;
>>>
>>> +	/* We can handle the block number less than F2FS_MAX_BLOCKS */
>>> +	if (unlikely(map->m_lblk >= F2FS_MAX_BLOCKS))
>>> +		return -EUCLEAN;

EFBIG ?

>>> +
>>>   	/* it only supports block size == page size */
>>>   	pgofs =	(pgoff_t)map->m_lblk;
>>>
>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>> index 19beabe..911c99b 100644
>>> --- a/fs/f2fs/f2fs.h
>>> +++ b/fs/f2fs/f2fs.h
>>> @@ -331,6 +331,9 @@ enum {
>>>
>>>   #define F2FS_LINK_MAX	0xffffffff	/* maximum link count per file */
>>>
>>> +
>>> +#define F2FS_MAX_BLOCKS 0x3F015AFF      /* maximum block count per file */

Can you introduce F2FS_MAX_BLOCKS with calculation detail of constant
'0x3F015AFF', moreover need to exclude reserved space for inline xattr.

Thanks,

>>> +
>>>   #define MAX_DIR_RA_PAGES	4	/* maximum ra pages of dir */
>>>
>>>   /* vector size for gang look-up from extent cache that consists of radix tree */
>>> --
>>> 1.9.1
>>
>>
>>
>> .
>
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 

------------------------------------------------------------------------------

  reply	other threads:[~2015-12-26 13:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-25  8:47 [PATCH] f2fs: add a max block count for f2fs_map_blocks Yunlei He
2015-12-25  9:25 ` Chao Yu
2015-12-25 10:17   ` liuxue
2015-12-26 13:21     ` Chao Yu [this message]
2015-12-28 13:03       ` He YunLei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=567E943C.6050905@kernel.org \
    --to=chao@kernel.org \
    --cc=heyunlei@huawei.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=liuxueliu.liu@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).