Hello,
syzbot found the following crash on:
HEAD commit:d9bd94c0bcaa Add linux-next specific files for 20180801
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1001189c40
kernel config: https://syzkaller.appspot.com/x/.config?x=cc8964ea4d04518c
On 2018/8/1 14:56, Chao Yu wrote:
Hi Sheng,
On 2018/8/1 11:46, Sheng Yong wrote:
Fixes: 652d19558a347 ('f2fs: fix to do sanity check with block address in main
area')
Reported-by: Zhang Xiaobo
Signed-off-by: Sheng Yong
That's my bad, and thanks for the fix.
Do you mind merge this into
Hi Junling,
On 2018/7/31 13:21, Junling Zheng wrote:
> Remove unused cp_blkaddr in f2fs_sanity_check_ckpt().
Since this issue is introduced by recent change, and the related patch has not
been upstreamed yet, can we merge this into that patch, if you don't mind?
Thanks,
>
> Signed-off-by:
Hi Sheng,
On 2018/8/1 11:46, Sheng Yong wrote:
> Fixes: 652d19558a347 ('f2fs: fix to do sanity check with block address in
> main area')
> Reported-by: Zhang Xiaobo
> Signed-off-by: Sheng Yong
That's my bad, and thanks for the fix.
Do you mind merge this into buggy patch, since the patch has
On 2018/8/1 14:54, Chao Yu wrote:
> Hi Junling,
>
> On 2018/7/31 13:21, Junling Zheng wrote:
>> Remove unused cp_blkaddr in f2fs_sanity_check_ckpt().
>
> Since this issue is introduced by recent change, and the related patch has not
> been upstreamed yet, can we merge this into that patch, if
On 2018/8/1 15:36, Sheng Yong wrote:
>
>
> On 2018/8/1 14:56, Chao Yu wrote:
>> Hi Sheng,
>>
>> On 2018/8/1 11:46, Sheng Yong wrote:
>>> Fixes: 652d19558a347 ('f2fs: fix to do sanity check with block address in
>>> main area')
>>> Reported-by: Zhang Xiaobo
>>> Signed-off-by: Sheng Yong
>>
>>
On 2018/8/1 18:26, Chao Yu wrote:
On 2018/8/1 15:36, Sheng Yong wrote:
On 2018/8/1 14:56, Chao Yu wrote:
Hi Sheng,
On 2018/8/1 11:46, Sheng Yong wrote:
Fixes: 652d19558a347 ('f2fs: fix to do sanity check with block address in main
area')
Reported-by: Zhang Xiaobo
Signed-off-by: Sheng
This patch add to do sanity check with below field:
- cp_pack_total_block_count
- blkaddr of data/node
- extent info
- Overview
BUG() in verify_block_addr() when writing to a corrupted f2fs image
- Reproduce (4.18 upstream kernel)
- POC (poc.c)
static void activity(char *mpoint) {
char
After fuzzing, cp_pack_start_sum could be corrupted, so current log's
summary info should be wrong due to loading incorrect summary block.
Then, if segment's type in current log is exceeded NR_CURSEG_TYPE, it
can lead accessing invalid dirty_i->dirty_segmap bitmap finally.
Add sanity check for
On 08/01, Chao Yu wrote:
> From: Chao Yu
>
> syzbot found the following crash on:
>
> HEAD commit:d9bd94c0bcaa Add linux-next specific files for 20180801
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1001189c40
&g
There is a subtle race condition to invoke f2fs_bug_on() in shutdown tests. I've
confirmed that the last checkpoint is preserved in consistent state, so it'd be
fine to just return error at this moment.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/node.c | 4
1 file changed, 4 insertions(+)
From: Chao Yu
syzbot found the following crash on:
HEAD commit:d9bd94c0bcaa Add linux-next specific files for 20180801
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1001189c40
kernel config: https://syzkaller.appspot.com/x/.config?x
On 2018/8/2 4:34, Jaegeuk Kim wrote:
> On 07/29, Chao Yu wrote:
>> From: Chao Yu
>>
>> f2fs recovery flow is relying on dnode block link list, it means fsynced
>> file recovery depends on previous dnode's persistence in the list, so
>> during fsync() we should wait on all regular inode's dnode
Return statements in functions returning bool should use true or false
instead of an integer value.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
fs/f2fs/f2fs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/f2fs.h
On 2018/8/2 2:58, Jaegeuk Kim wrote:
> On 08/01, Chao Yu wrote:
>> From: Chao Yu
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:d9bd94c0bcaa Add linux-next specific files for 20180801
>> git tree: linux-next
>> console outp
On 07/29, Chao Yu wrote:
> From: Chao Yu
>
> f2fs recovery flow is relying on dnode block link list, it means fsynced
> file recovery depends on previous dnode's persistence in the list, so
> during fsync() we should wait on all regular inode's dnode writebacked
> before issuing flush.
>
> By
16 matches
Mail list logo