>On 09/15, wangzijie wrote:
>> When we get wrong extent info data, and look up extent_node in rb tree,
>> it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by
>> return NULL.
>
>This is the exact buggy case which we should fix the original one. Have
>you seen this error? In that case, can we consider writing some kernel
>message and handle the error properly?
Hi Jaegeuk,
The original one is the bug I mentioned in the first patch of this patch set
("f2fs: fix zero-sized extent for precache extents").
When we use a wrong extent_info(zero-sized) to do update, and there exists a
extent_node which has same fofs as the wrong one, we will skip "invalidate all
extent
nodes in range [fofs, fofs + len - 1]"(en->ei.fofs = end = tei->fofs + tei->len
= tei->fofs),
which cause the infinite loop in __insert_extent_tree().
So we can add f2fs_bug_on() when there occurs zero-sized extent
in f2fs_update_read_extent_cache_range(), and give up this zero-sized
extent update to handle other unknown buggy cases. Do you think this will be
better?
And do we need to solve this infinite loop?
>>
>> Signed-off-by: wangzijie <[email protected]>
>> ---
>> fs/f2fs/extent_cache.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
>> index 199c1e7a8..6ed6f3d1d 100644
>> --- a/fs/f2fs/extent_cache.c
>> +++ b/fs/f2fs/extent_cache.c
>> @@ -605,6 +605,7 @@ static struct extent_node *__insert_extent_tree(struct
>> f2fs_sb_info *sbi,
>> leftmost = false;
>> } else {
>> f2fs_bug_on(sbi, 1);
>> + return NULL;
>> }
>> }
>>
>> --
>> 2.25.1
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
