* Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
@ 2022-04-11 3:09 ` Chao Yu
0 siblings, 0 replies; 20+ messages in thread
From: Chao Yu @ 2022-04-11 3:09 UTC (permalink / raw)
To: Dongliang Mu
Cc: Jaegeuk Kim, Dongliang Mu, linux-kernel,
syzbot+763ae12a2ede1d99d4dc, linux-f2fs-devel
On 2022/4/9 14:42, Dongliang Mu wrote:
> On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@kernel.org> wrote:
>>
>> On 2022/4/9 9:34, Dongliang Mu wrote:
>>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@kernel.org> wrote:
>>>>
>>>> On 2022/4/8 13:22, Dongliang Mu wrote:
>>>>> From: Dongliang Mu <mudongliangabcd@gmail.com>
>>>>>
>>>>> In f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or
>>>>> DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON(1) not matter
>>>>> blkaddr is in the range or not.
>>>>
>>>> If we run into the path where we invoke WARN_ON(1) in f2fs_is_valid_blkaddr(),
>>>> It means f2fs image may be broken, or there is a bug in f2fs.
>>>>
>>>> So, do you suffer any related issue in your environment?
>>>
>>> related issue? Can you explain a little?
>>>
>>> If you mean if this warning occurs, any other issues or crash
>>
>> I mean have you seen any warning info printed in the path of
>> f2fs_is_valid_blkaddr() before applying this patch, and if so, w/ what
>> reproducer? or you just figure out this patch from perspective of code
>> review?
>
> Yes, I have seen both warning information from Syzbot [1] and my local
> syzkaller instance.
>
> In f2fs_is_valid_blkaddr, if the following condition is satisfied,
> i.e., blkaddr is not in the right range [2], it will directly invoke
> one WARN_ON.
>
> if (unlikely(blkaddr >= MAX_BLKADDR(sbi) ||
> blkaddr < MAIN_BLKADDR(sbi))) {
>
> This is the case on Syzbot.
>
> Otherwise, it will jump into __is_bitmap_valid. And if the following
> condition is satisfied [3], it will trigger another WARN_ON.
>
> exist = f2fs_test_bit(offset, se->cur_valid_map);
> if (!exist && type == DATA_GENERIC_ENHANCE) {
>
> This appears in my local syzbot instance, but unfortunately it does
> not get any reproducer.
Oh, it occurs in syzbot test, I guess it is possible that f2fs prints such
warning info after blkaddr of node/data block was fuzzed to invalid one.
I prefer to keep WARN_ON() to catch more info of bugs found by non-fuzzed
type test.
Thoughts?
Thanks,
>
> [1] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fbug%3Fextid%3D763ae12a2ede1d99d4dc&data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UVSSS9IknYLJHzqqJAN5HmPgJ8GNczvi6%2FuQf2n3vlY%3D&reserved=0
> [2] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Ffs%2Ff2fs%2Fcheckpoint.c%23L187&data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Sf%2Bx8WCAXf5c4%2Bins46saTsTN5uNTrnIceAP3oCWnQw%3D&reserved=0
> [3] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Ffs%2Ff2fs%2Fcheckpoint.c%23L135&data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ly%2FBL5oFAWZmXwbN6TaYCExroDE8%2Fsli1alaJwR4wvU%3D&reserved=0
>
>
>>
>> Thanks,
>>
>>> behaviors are generated? I tested on the syzbot. After removing the
>>> WARN_ON, there is no abnormal issue or crash behaviors followed with
>>> the corresponding reproducer.
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>>>
>>>>> Fix this by removing WARN_ON.
>>>>>
>>>>> Note that, syzbot patch testing does not incur any further issues
>>>>>
>>>>> Reported-by: syzbot+763ae12a2ede1d99d4dc@syzkaller.appspotmail.com
>>>>> Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
>>>>> ---
>>>>> fs/f2fs/checkpoint.c | 2 --
>>>>> 1 file changed, 2 deletions(-)
>>>>>
>>>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>>>> index f5366feea82d..521498b2dd8c 100644
>>>>> --- a/fs/f2fs/checkpoint.c
>>>>> +++ b/fs/f2fs/checkpoint.c
>>>>> @@ -158,7 +158,6 @@ static bool __is_bitmap_valid(struct f2fs_sb_info *sbi, block_t blkaddr,
>>>>> f2fs_err(sbi, "Inconsistent error blkaddr:%u, sit bitmap:%d",
>>>>> blkaddr, exist);
>>>>> set_sbi_flag(sbi, SBI_NEED_FSCK);
>>>>> - WARN_ON(1);
>>>>> }
>>>>> return exist;
>>>>> }
>>>>> @@ -196,7 +195,6 @@ bool f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi,
>>>>> f2fs_warn(sbi, "access invalid blkaddr:%u",
>>>>> blkaddr);
>>>>> set_sbi_flag(sbi, SBI_NEED_FSCK);
>>>>> - WARN_ON(1);
>>>>> return false;
>>>>> } else {
>>>>> return __is_bitmap_valid(sbi, blkaddr, type);
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
2022-04-11 3:09 ` Chao Yu
@ 2022-04-11 5:06 ` Dongliang Mu
-1 siblings, 0 replies; 20+ messages in thread
From: Dongliang Mu @ 2022-04-11 5:06 UTC (permalink / raw)
To: Chao Yu, Dmitry Vyukov
Cc: Jaegeuk Kim, Dongliang Mu, linux-kernel,
syzbot+763ae12a2ede1d99d4dc, linux-f2fs-devel
On Mon, Apr 11, 2022 at 11:10 AM Chao Yu <chao@kernel.org> wrote:
>
> On 2022/4/9 14:42, Dongliang Mu wrote:
> > On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@kernel.org> wrote:
> >>
> >> On 2022/4/9 9:34, Dongliang Mu wrote:
> >>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@kernel.org> wrote:
> >>>>
> >>>> On 2022/4/8 13:22, Dongliang Mu wrote:
> >>>>> From: Dongliang Mu <mudongliangabcd@gmail.com>
> >>>>>
> >>>>> In f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or
> >>>>> DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON(1) not matter
> >>>>> blkaddr is in the range or not.
> >>>>
> >>>> If we run into the path where we invoke WARN_ON(1) in f2fs_is_valid_blkaddr(),
> >>>> It means f2fs image may be broken, or there is a bug in f2fs.
> >>>>
> >>>> So, do you suffer any related issue in your environment?
> >>>
> >>> related issue? Can you explain a little?
> >>>
> >>> If you mean if this warning occurs, any other issues or crash
> >>
> >> I mean have you seen any warning info printed in the path of
> >> f2fs_is_valid_blkaddr() before applying this patch, and if so, w/ what
> >> reproducer? or you just figure out this patch from perspective of code
> >> review?
> >
> > Yes, I have seen both warning information from Syzbot [1] and my local
> > syzkaller instance.
> >
> > In f2fs_is_valid_blkaddr, if the following condition is satisfied,
> > i.e., blkaddr is not in the right range [2], it will directly invoke
> > one WARN_ON.
> >
> > if (unlikely(blkaddr >= MAX_BLKADDR(sbi) ||
> > blkaddr < MAIN_BLKADDR(sbi))) {
> >
> > This is the case on Syzbot.
> >
> > Otherwise, it will jump into __is_bitmap_valid. And if the following
> > condition is satisfied [3], it will trigger another WARN_ON.
> >
> > exist = f2fs_test_bit(offset, se->cur_valid_map);
> > if (!exist && type == DATA_GENERIC_ENHANCE) {
> >
> > This appears in my local syzbot instance, but unfortunately it does
> > not get any reproducer.
>
> Oh, it occurs in syzbot test, I guess it is possible that f2fs prints such
> warning info after blkaddr of node/data block was fuzzed to invalid one.
>
> I prefer to keep WARN_ON() to catch more info of bugs found by non-fuzzed
> type test.
>
> Thoughts?
I am fine with both options. I can remove the WARN_ON in my local
syzkaller instance and continue fuzzing Linux kernel.
+Dmitry Vyukov how do you think? If WARN_ON is kept, this crash will
occur on Syzbot from time to time.
>
> Thanks,
>
> >
> > [1] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fbug%3Fextid%3D763ae12a2ede1d99d4dc&data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UVSSS9IknYLJHzqqJAN5HmPgJ8GNczvi6%2FuQf2n3vlY%3D&reserved=0
> > [2] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Ffs%2Ff2fs%2Fcheckpoint.c%23L187&data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Sf%2Bx8WCAXf5c4%2Bins46saTsTN5uNTrnIceAP3oCWnQw%3D&reserved=0
> > [3] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Ffs%2Ff2fs%2Fcheckpoint.c%23L135&data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ly%2FBL5oFAWZmXwbN6TaYCExroDE8%2Fsli1alaJwR4wvU%3D&reserved=0
> >
> >
> >>
> >> Thanks,
> >>
> >>> behaviors are generated? I tested on the syzbot. After removing the
> >>> WARN_ON, there is no abnormal issue or crash behaviors followed with
> >>> the corresponding reproducer.
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>>>
> >>>>> Fix this by removing WARN_ON.
> >>>>>
> >>>>> Note that, syzbot patch testing does not incur any further issues
> >>>>>
> >>>>> Reported-by: syzbot+763ae12a2ede1d99d4dc@syzkaller.appspotmail.com
> >>>>> Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
> >>>>> ---
> >>>>> fs/f2fs/checkpoint.c | 2 --
> >>>>> 1 file changed, 2 deletions(-)
> >>>>>
> >>>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> >>>>> index f5366feea82d..521498b2dd8c 100644
> >>>>> --- a/fs/f2fs/checkpoint.c
> >>>>> +++ b/fs/f2fs/checkpoint.c
> >>>>> @@ -158,7 +158,6 @@ static bool __is_bitmap_valid(struct f2fs_sb_info *sbi, block_t blkaddr,
> >>>>> f2fs_err(sbi, "Inconsistent error blkaddr:%u, sit bitmap:%d",
> >>>>> blkaddr, exist);
> >>>>> set_sbi_flag(sbi, SBI_NEED_FSCK);
> >>>>> - WARN_ON(1);
> >>>>> }
> >>>>> return exist;
> >>>>> }
> >>>>> @@ -196,7 +195,6 @@ bool f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi,
> >>>>> f2fs_warn(sbi, "access invalid blkaddr:%u",
> >>>>> blkaddr);
> >>>>> set_sbi_flag(sbi, SBI_NEED_FSCK);
> >>>>> - WARN_ON(1);
> >>>>> return false;
> >>>>> } else {
> >>>>> return __is_bitmap_valid(sbi, blkaddr, type);
> >
> >
> > _______________________________________________
> > Linux-f2fs-devel mailing list
> > Linux-f2fs-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
@ 2022-04-11 5:06 ` Dongliang Mu
0 siblings, 0 replies; 20+ messages in thread
From: Dongliang Mu @ 2022-04-11 5:06 UTC (permalink / raw)
To: Chao Yu, Dmitry Vyukov
Cc: Jaegeuk Kim, Dongliang Mu, linux-kernel,
syzbot+763ae12a2ede1d99d4dc, linux-f2fs-devel
On Mon, Apr 11, 2022 at 11:10 AM Chao Yu <chao@kernel.org> wrote:
>
> On 2022/4/9 14:42, Dongliang Mu wrote:
> > On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@kernel.org> wrote:
> >>
> >> On 2022/4/9 9:34, Dongliang Mu wrote:
> >>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@kernel.org> wrote:
> >>>>
> >>>> On 2022/4/8 13:22, Dongliang Mu wrote:
> >>>>> From: Dongliang Mu <mudongliangabcd@gmail.com>
> >>>>>
> >>>>> In f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or
> >>>>> DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON(1) not matter
> >>>>> blkaddr is in the range or not.
> >>>>
> >>>> If we run into the path where we invoke WARN_ON(1) in f2fs_is_valid_blkaddr(),
> >>>> It means f2fs image may be broken, or there is a bug in f2fs.
> >>>>
> >>>> So, do you suffer any related issue in your environment?
> >>>
> >>> related issue? Can you explain a little?
> >>>
> >>> If you mean if this warning occurs, any other issues or crash
> >>
> >> I mean have you seen any warning info printed in the path of
> >> f2fs_is_valid_blkaddr() before applying this patch, and if so, w/ what
> >> reproducer? or you just figure out this patch from perspective of code
> >> review?
> >
> > Yes, I have seen both warning information from Syzbot [1] and my local
> > syzkaller instance.
> >
> > In f2fs_is_valid_blkaddr, if the following condition is satisfied,
> > i.e., blkaddr is not in the right range [2], it will directly invoke
> > one WARN_ON.
> >
> > if (unlikely(blkaddr >= MAX_BLKADDR(sbi) ||
> > blkaddr < MAIN_BLKADDR(sbi))) {
> >
> > This is the case on Syzbot.
> >
> > Otherwise, it will jump into __is_bitmap_valid. And if the following
> > condition is satisfied [3], it will trigger another WARN_ON.
> >
> > exist = f2fs_test_bit(offset, se->cur_valid_map);
> > if (!exist && type == DATA_GENERIC_ENHANCE) {
> >
> > This appears in my local syzbot instance, but unfortunately it does
> > not get any reproducer.
>
> Oh, it occurs in syzbot test, I guess it is possible that f2fs prints such
> warning info after blkaddr of node/data block was fuzzed to invalid one.
>
> I prefer to keep WARN_ON() to catch more info of bugs found by non-fuzzed
> type test.
>
> Thoughts?
I am fine with both options. I can remove the WARN_ON in my local
syzkaller instance and continue fuzzing Linux kernel.
+Dmitry Vyukov how do you think? If WARN_ON is kept, this crash will
occur on Syzbot from time to time.
>
> Thanks,
>
> >
> > [1] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsyzkaller.appspot.com%2Fbug%3Fextid%3D763ae12a2ede1d99d4dc&data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UVSSS9IknYLJHzqqJAN5HmPgJ8GNczvi6%2FuQf2n3vlY%3D&reserved=0
> > [2] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Ffs%2Ff2fs%2Fcheckpoint.c%23L187&data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Sf%2Bx8WCAXf5c4%2Bins46saTsTN5uNTrnIceAP3oCWnQw%3D&reserved=0
> > [3] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Ffs%2Ff2fs%2Fcheckpoint.c%23L135&data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ly%2FBL5oFAWZmXwbN6TaYCExroDE8%2Fsli1alaJwR4wvU%3D&reserved=0
> >
> >
> >>
> >> Thanks,
> >>
> >>> behaviors are generated? I tested on the syzbot. After removing the
> >>> WARN_ON, there is no abnormal issue or crash behaviors followed with
> >>> the corresponding reproducer.
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>>>
> >>>>> Fix this by removing WARN_ON.
> >>>>>
> >>>>> Note that, syzbot patch testing does not incur any further issues
> >>>>>
> >>>>> Reported-by: syzbot+763ae12a2ede1d99d4dc@syzkaller.appspotmail.com
> >>>>> Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
> >>>>> ---
> >>>>> fs/f2fs/checkpoint.c | 2 --
> >>>>> 1 file changed, 2 deletions(-)
> >>>>>
> >>>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> >>>>> index f5366feea82d..521498b2dd8c 100644
> >>>>> --- a/fs/f2fs/checkpoint.c
> >>>>> +++ b/fs/f2fs/checkpoint.c
> >>>>> @@ -158,7 +158,6 @@ static bool __is_bitmap_valid(struct f2fs_sb_info *sbi, block_t blkaddr,
> >>>>> f2fs_err(sbi, "Inconsistent error blkaddr:%u, sit bitmap:%d",
> >>>>> blkaddr, exist);
> >>>>> set_sbi_flag(sbi, SBI_NEED_FSCK);
> >>>>> - WARN_ON(1);
> >>>>> }
> >>>>> return exist;
> >>>>> }
> >>>>> @@ -196,7 +195,6 @@ bool f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi,
> >>>>> f2fs_warn(sbi, "access invalid blkaddr:%u",
> >>>>> blkaddr);
> >>>>> set_sbi_flag(sbi, SBI_NEED_FSCK);
> >>>>> - WARN_ON(1);
> >>>>> return false;
> >>>>> } else {
> >>>>> return __is_bitmap_valid(sbi, blkaddr, type);
> >
> >
> > _______________________________________________
> > Linux-f2fs-devel mailing list
> > Linux-f2fs-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
2022-04-11 5:06 ` Dongliang Mu
@ 2022-04-11 6:14 ` Eric Biggers
-1 siblings, 0 replies; 20+ messages in thread
From: Eric Biggers @ 2022-04-11 6:14 UTC (permalink / raw)
To: Dongliang Mu
Cc: Chao Yu, Dmitry Vyukov, Jaegeuk Kim, Dongliang Mu, linux-kernel,
syzbot+763ae12a2ede1d99d4dc, linux-f2fs-devel
On Mon, Apr 11, 2022 at 01:06:09PM +0800, Dongliang Mu wrote:
> On Mon, Apr 11, 2022 at 11:10 AM Chao Yu <chao@kernel.org> wrote:
> >
> > On 2022/4/9 14:42, Dongliang Mu wrote:
> > > On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@kernel.org> wrote:
> > >>
> > >> On 2022/4/9 9:34, Dongliang Mu wrote:
> > >>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@kernel.org> wrote:
> > >>>>
> > >>>> On 2022/4/8 13:22, Dongliang Mu wrote:
> > >>>>> From: Dongliang Mu <mudongliangabcd@gmail.com>
> > >>>>>
> > >>>>> In f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or
> > >>>>> DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON(1) not matter
> > >>>>> blkaddr is in the range or not.
> > >>>>
> > >>>> If we run into the path where we invoke WARN_ON(1) in f2fs_is_valid_blkaddr(),
> > >>>> It means f2fs image may be broken, or there is a bug in f2fs.
> > >>>>
> > >>>> So, do you suffer any related issue in your environment?
> > >>>
> > >>> related issue? Can you explain a little?
> > >>>
> > >>> If you mean if this warning occurs, any other issues or crash
> > >>
> > >> I mean have you seen any warning info printed in the path of
> > >> f2fs_is_valid_blkaddr() before applying this patch, and if so, w/ what
> > >> reproducer? or you just figure out this patch from perspective of code
> > >> review?
> > >
> > > Yes, I have seen both warning information from Syzbot [1] and my local
> > > syzkaller instance.
> > >
> > > In f2fs_is_valid_blkaddr, if the following condition is satisfied,
> > > i.e., blkaddr is not in the right range [2], it will directly invoke
> > > one WARN_ON.
> > >
> > > if (unlikely(blkaddr >= MAX_BLKADDR(sbi) ||
> > > blkaddr < MAIN_BLKADDR(sbi))) {
> > >
> > > This is the case on Syzbot.
> > >
> > > Otherwise, it will jump into __is_bitmap_valid. And if the following
> > > condition is satisfied [3], it will trigger another WARN_ON.
> > >
> > > exist = f2fs_test_bit(offset, se->cur_valid_map);
> > > if (!exist && type == DATA_GENERIC_ENHANCE) {
> > >
> > > This appears in my local syzbot instance, but unfortunately it does
> > > not get any reproducer.
> >
> > Oh, it occurs in syzbot test, I guess it is possible that f2fs prints such
> > warning info after blkaddr of node/data block was fuzzed to invalid one.
> >
> > I prefer to keep WARN_ON() to catch more info of bugs found by non-fuzzed
> > type test.
> >
> > Thoughts?
>
> I am fine with both options. I can remove the WARN_ON in my local
> syzkaller instance and continue fuzzing Linux kernel.
>
> +Dmitry Vyukov how do you think? If WARN_ON is kept, this crash will
> occur on Syzbot from time to time.
WARN_ON is for kernel bugs; please refer to the documentation in
include/asm-generic/bug.h. If this is a kernel bug, then the kernel bug needs
to be fixed. Otherwise, the WARN_ON needs to be removed.
- Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
@ 2022-04-11 6:14 ` Eric Biggers
0 siblings, 0 replies; 20+ messages in thread
From: Eric Biggers @ 2022-04-11 6:14 UTC (permalink / raw)
To: Dongliang Mu
Cc: syzbot+763ae12a2ede1d99d4dc, linux-kernel, linux-f2fs-devel,
Dongliang Mu, Jaegeuk Kim, Dmitry Vyukov
On Mon, Apr 11, 2022 at 01:06:09PM +0800, Dongliang Mu wrote:
> On Mon, Apr 11, 2022 at 11:10 AM Chao Yu <chao@kernel.org> wrote:
> >
> > On 2022/4/9 14:42, Dongliang Mu wrote:
> > > On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@kernel.org> wrote:
> > >>
> > >> On 2022/4/9 9:34, Dongliang Mu wrote:
> > >>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@kernel.org> wrote:
> > >>>>
> > >>>> On 2022/4/8 13:22, Dongliang Mu wrote:
> > >>>>> From: Dongliang Mu <mudongliangabcd@gmail.com>
> > >>>>>
> > >>>>> In f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or
> > >>>>> DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON(1) not matter
> > >>>>> blkaddr is in the range or not.
> > >>>>
> > >>>> If we run into the path where we invoke WARN_ON(1) in f2fs_is_valid_blkaddr(),
> > >>>> It means f2fs image may be broken, or there is a bug in f2fs.
> > >>>>
> > >>>> So, do you suffer any related issue in your environment?
> > >>>
> > >>> related issue? Can you explain a little?
> > >>>
> > >>> If you mean if this warning occurs, any other issues or crash
> > >>
> > >> I mean have you seen any warning info printed in the path of
> > >> f2fs_is_valid_blkaddr() before applying this patch, and if so, w/ what
> > >> reproducer? or you just figure out this patch from perspective of code
> > >> review?
> > >
> > > Yes, I have seen both warning information from Syzbot [1] and my local
> > > syzkaller instance.
> > >
> > > In f2fs_is_valid_blkaddr, if the following condition is satisfied,
> > > i.e., blkaddr is not in the right range [2], it will directly invoke
> > > one WARN_ON.
> > >
> > > if (unlikely(blkaddr >= MAX_BLKADDR(sbi) ||
> > > blkaddr < MAIN_BLKADDR(sbi))) {
> > >
> > > This is the case on Syzbot.
> > >
> > > Otherwise, it will jump into __is_bitmap_valid. And if the following
> > > condition is satisfied [3], it will trigger another WARN_ON.
> > >
> > > exist = f2fs_test_bit(offset, se->cur_valid_map);
> > > if (!exist && type == DATA_GENERIC_ENHANCE) {
> > >
> > > This appears in my local syzbot instance, but unfortunately it does
> > > not get any reproducer.
> >
> > Oh, it occurs in syzbot test, I guess it is possible that f2fs prints such
> > warning info after blkaddr of node/data block was fuzzed to invalid one.
> >
> > I prefer to keep WARN_ON() to catch more info of bugs found by non-fuzzed
> > type test.
> >
> > Thoughts?
>
> I am fine with both options. I can remove the WARN_ON in my local
> syzkaller instance and continue fuzzing Linux kernel.
>
> +Dmitry Vyukov how do you think? If WARN_ON is kept, this crash will
> occur on Syzbot from time to time.
WARN_ON is for kernel bugs; please refer to the documentation in
include/asm-generic/bug.h. If this is a kernel bug, then the kernel bug needs
to be fixed. Otherwise, the WARN_ON needs to be removed.
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
2022-04-11 6:14 ` Eric Biggers
@ 2022-04-11 9:53 ` Chao Yu
-1 siblings, 0 replies; 20+ messages in thread
From: Chao Yu @ 2022-04-11 9:53 UTC (permalink / raw)
To: Eric Biggers, Dongliang Mu
Cc: Dmitry Vyukov, Jaegeuk Kim, Dongliang Mu, linux-kernel,
syzbot+763ae12a2ede1d99d4dc, linux-f2fs-devel
On 2022/4/11 14:14, Eric Biggers wrote:
> On Mon, Apr 11, 2022 at 01:06:09PM +0800, Dongliang Mu wrote:
>> On Mon, Apr 11, 2022 at 11:10 AM Chao Yu <chao@kernel.org> wrote:
>>>
>>> On 2022/4/9 14:42, Dongliang Mu wrote:
>>>> On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@kernel.org> wrote:
>>>>>
>>>>> On 2022/4/9 9:34, Dongliang Mu wrote:
>>>>>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@kernel.org> wrote:
>>>>>>>
>>>>>>> On 2022/4/8 13:22, Dongliang Mu wrote:
>>>>>>>> From: Dongliang Mu <mudongliangabcd@gmail.com>
>>>>>>>>
>>>>>>>> In f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or
>>>>>>>> DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON(1) not matter
>>>>>>>> blkaddr is in the range or not.
>>>>>>>
>>>>>>> If we run into the path where we invoke WARN_ON(1) in f2fs_is_valid_blkaddr(),
>>>>>>> It means f2fs image may be broken, or there is a bug in f2fs.
>>>>>>>
>>>>>>> So, do you suffer any related issue in your environment?
>>>>>>
>>>>>> related issue? Can you explain a little?
>>>>>>
>>>>>> If you mean if this warning occurs, any other issues or crash
>>>>>
>>>>> I mean have you seen any warning info printed in the path of
>>>>> f2fs_is_valid_blkaddr() before applying this patch, and if so, w/ what
>>>>> reproducer? or you just figure out this patch from perspective of code
>>>>> review?
>>>>
>>>> Yes, I have seen both warning information from Syzbot [1] and my local
>>>> syzkaller instance.
>>>>
>>>> In f2fs_is_valid_blkaddr, if the following condition is satisfied,
>>>> i.e., blkaddr is not in the right range [2], it will directly invoke
>>>> one WARN_ON.
>>>>
>>>> if (unlikely(blkaddr >= MAX_BLKADDR(sbi) ||
>>>> blkaddr < MAIN_BLKADDR(sbi))) {
>>>>
>>>> This is the case on Syzbot.
>>>>
>>>> Otherwise, it will jump into __is_bitmap_valid. And if the following
>>>> condition is satisfied [3], it will trigger another WARN_ON.
>>>>
>>>> exist = f2fs_test_bit(offset, se->cur_valid_map);
>>>> if (!exist && type == DATA_GENERIC_ENHANCE) {
>>>>
>>>> This appears in my local syzbot instance, but unfortunately it does
>>>> not get any reproducer.
>>>
>>> Oh, it occurs in syzbot test, I guess it is possible that f2fs prints such
>>> warning info after blkaddr of node/data block was fuzzed to invalid one.
>>>
>>> I prefer to keep WARN_ON() to catch more info of bugs found by non-fuzzed
>>> type test.
>>>
>>> Thoughts?
>>
>> I am fine with both options. I can remove the WARN_ON in my local
>> syzkaller instance and continue fuzzing Linux kernel.
>>
>> +Dmitry Vyukov how do you think? If WARN_ON is kept, this crash will
>> occur on Syzbot from time to time.
>
> WARN_ON is for kernel bugs; please refer to the documentation in
> include/asm-generic/bug.h. If this is a kernel bug, then the kernel bug needs
> to be fixed. Otherwise, the WARN_ON needs to be removed.
Alright, so how about using dump_stack() instead as suggested in doc?
Thanks,
>
> - Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
@ 2022-04-11 9:53 ` Chao Yu
0 siblings, 0 replies; 20+ messages in thread
From: Chao Yu @ 2022-04-11 9:53 UTC (permalink / raw)
To: Eric Biggers, Dongliang Mu
Cc: syzbot+763ae12a2ede1d99d4dc, linux-kernel, linux-f2fs-devel,
Dongliang Mu, Jaegeuk Kim, Dmitry Vyukov
On 2022/4/11 14:14, Eric Biggers wrote:
> On Mon, Apr 11, 2022 at 01:06:09PM +0800, Dongliang Mu wrote:
>> On Mon, Apr 11, 2022 at 11:10 AM Chao Yu <chao@kernel.org> wrote:
>>>
>>> On 2022/4/9 14:42, Dongliang Mu wrote:
>>>> On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@kernel.org> wrote:
>>>>>
>>>>> On 2022/4/9 9:34, Dongliang Mu wrote:
>>>>>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@kernel.org> wrote:
>>>>>>>
>>>>>>> On 2022/4/8 13:22, Dongliang Mu wrote:
>>>>>>>> From: Dongliang Mu <mudongliangabcd@gmail.com>
>>>>>>>>
>>>>>>>> In f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or
>>>>>>>> DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON(1) not matter
>>>>>>>> blkaddr is in the range or not.
>>>>>>>
>>>>>>> If we run into the path where we invoke WARN_ON(1) in f2fs_is_valid_blkaddr(),
>>>>>>> It means f2fs image may be broken, or there is a bug in f2fs.
>>>>>>>
>>>>>>> So, do you suffer any related issue in your environment?
>>>>>>
>>>>>> related issue? Can you explain a little?
>>>>>>
>>>>>> If you mean if this warning occurs, any other issues or crash
>>>>>
>>>>> I mean have you seen any warning info printed in the path of
>>>>> f2fs_is_valid_blkaddr() before applying this patch, and if so, w/ what
>>>>> reproducer? or you just figure out this patch from perspective of code
>>>>> review?
>>>>
>>>> Yes, I have seen both warning information from Syzbot [1] and my local
>>>> syzkaller instance.
>>>>
>>>> In f2fs_is_valid_blkaddr, if the following condition is satisfied,
>>>> i.e., blkaddr is not in the right range [2], it will directly invoke
>>>> one WARN_ON.
>>>>
>>>> if (unlikely(blkaddr >= MAX_BLKADDR(sbi) ||
>>>> blkaddr < MAIN_BLKADDR(sbi))) {
>>>>
>>>> This is the case on Syzbot.
>>>>
>>>> Otherwise, it will jump into __is_bitmap_valid. And if the following
>>>> condition is satisfied [3], it will trigger another WARN_ON.
>>>>
>>>> exist = f2fs_test_bit(offset, se->cur_valid_map);
>>>> if (!exist && type == DATA_GENERIC_ENHANCE) {
>>>>
>>>> This appears in my local syzbot instance, but unfortunately it does
>>>> not get any reproducer.
>>>
>>> Oh, it occurs in syzbot test, I guess it is possible that f2fs prints such
>>> warning info after blkaddr of node/data block was fuzzed to invalid one.
>>>
>>> I prefer to keep WARN_ON() to catch more info of bugs found by non-fuzzed
>>> type test.
>>>
>>> Thoughts?
>>
>> I am fine with both options. I can remove the WARN_ON in my local
>> syzkaller instance and continue fuzzing Linux kernel.
>>
>> +Dmitry Vyukov how do you think? If WARN_ON is kept, this crash will
>> occur on Syzbot from time to time.
>
> WARN_ON is for kernel bugs; please refer to the documentation in
> include/asm-generic/bug.h. If this is a kernel bug, then the kernel bug needs
> to be fixed. Otherwise, the WARN_ON needs to be removed.
Alright, so how about using dump_stack() instead as suggested in doc?
Thanks,
>
> - Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
2022-04-11 9:53 ` Chao Yu
@ 2022-04-12 9:25 ` Dongliang Mu
-1 siblings, 0 replies; 20+ messages in thread
From: Dongliang Mu @ 2022-04-12 9:25 UTC (permalink / raw)
To: Chao Yu
Cc: syzbot+763ae12a2ede1d99d4dc, linux-kernel, linux-f2fs-devel,
Eric Biggers, Dongliang Mu, Jaegeuk Kim, Dmitry Vyukov
On Mon, Apr 11, 2022 at 5:53 PM Chao Yu <chao@kernel.org> wrote:
>
> On 2022/4/11 14:14, Eric Biggers wrote:
> > On Mon, Apr 11, 2022 at 01:06:09PM +0800, Dongliang Mu wrote:
> >> On Mon, Apr 11, 2022 at 11:10 AM Chao Yu <chao@kernel.org> wrote:
> >>>
> >>> On 2022/4/9 14:42, Dongliang Mu wrote:
> >>>> On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@kernel.org> wrote:
> >>>>>
> >>>>> On 2022/4/9 9:34, Dongliang Mu wrote:
> >>>>>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@kernel.org> wrote:
> >>>>>>>
> >>>>>>> On 2022/4/8 13:22, Dongliang Mu wrote:
> >>>>>>>> From: Dongliang Mu <mudongliangabcd@gmail.com>
> >>>>>>>>
> >>>>>>>> In f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or
> >>>>>>>> DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON(1) not matter
> >>>>>>>> blkaddr is in the range or not.
> >>>>>>>
> >>>>>>> If we run into the path where we invoke WARN_ON(1) in f2fs_is_valid_blkaddr(),
> >>>>>>> It means f2fs image may be broken, or there is a bug in f2fs.
> >>>>>>>
> >>>>>>> So, do you suffer any related issue in your environment?
> >>>>>>
> >>>>>> related issue? Can you explain a little?
> >>>>>>
> >>>>>> If you mean if this warning occurs, any other issues or crash
> >>>>>
> >>>>> I mean have you seen any warning info printed in the path of
> >>>>> f2fs_is_valid_blkaddr() before applying this patch, and if so, w/ what
> >>>>> reproducer? or you just figure out this patch from perspective of code
> >>>>> review?
> >>>>
> >>>> Yes, I have seen both warning information from Syzbot [1] and my local
> >>>> syzkaller instance.
> >>>>
> >>>> In f2fs_is_valid_blkaddr, if the following condition is satisfied,
> >>>> i.e., blkaddr is not in the right range [2], it will directly invoke
> >>>> one WARN_ON.
> >>>>
> >>>> if (unlikely(blkaddr >= MAX_BLKADDR(sbi) ||
> >>>> blkaddr < MAIN_BLKADDR(sbi))) {
> >>>>
> >>>> This is the case on Syzbot.
> >>>>
> >>>> Otherwise, it will jump into __is_bitmap_valid. And if the following
> >>>> condition is satisfied [3], it will trigger another WARN_ON.
> >>>>
> >>>> exist = f2fs_test_bit(offset, se->cur_valid_map);
> >>>> if (!exist && type == DATA_GENERIC_ENHANCE) {
> >>>>
> >>>> This appears in my local syzbot instance, but unfortunately it does
> >>>> not get any reproducer.
> >>>
> >>> Oh, it occurs in syzbot test, I guess it is possible that f2fs prints such
> >>> warning info after blkaddr of node/data block was fuzzed to invalid one.
> >>>
> >>> I prefer to keep WARN_ON() to catch more info of bugs found by non-fuzzed
> >>> type test.
> >>>
> >>> Thoughts?
> >>
> >> I am fine with both options. I can remove the WARN_ON in my local
> >> syzkaller instance and continue fuzzing Linux kernel.
> >>
> >> +Dmitry Vyukov how do you think? If WARN_ON is kept, this crash will
> >> occur on Syzbot from time to time.
> >
> > WARN_ON is for kernel bugs; please refer to the documentation in
> > include/asm-generic/bug.h. If this is a kernel bug, then the kernel bug needs
> > to be fixed. Otherwise, the WARN_ON needs to be removed.
>
> Alright, so how about using dump_stack() instead as suggested in doc?
I agree. Let's change WARN_ON to dump_stack().
>
> Thanks,
>
> >
> > - Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
@ 2022-04-12 9:25 ` Dongliang Mu
0 siblings, 0 replies; 20+ messages in thread
From: Dongliang Mu @ 2022-04-12 9:25 UTC (permalink / raw)
To: Chao Yu
Cc: Eric Biggers, Dmitry Vyukov, Jaegeuk Kim, Dongliang Mu,
linux-kernel, syzbot+763ae12a2ede1d99d4dc, linux-f2fs-devel
On Mon, Apr 11, 2022 at 5:53 PM Chao Yu <chao@kernel.org> wrote:
>
> On 2022/4/11 14:14, Eric Biggers wrote:
> > On Mon, Apr 11, 2022 at 01:06:09PM +0800, Dongliang Mu wrote:
> >> On Mon, Apr 11, 2022 at 11:10 AM Chao Yu <chao@kernel.org> wrote:
> >>>
> >>> On 2022/4/9 14:42, Dongliang Mu wrote:
> >>>> On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@kernel.org> wrote:
> >>>>>
> >>>>> On 2022/4/9 9:34, Dongliang Mu wrote:
> >>>>>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@kernel.org> wrote:
> >>>>>>>
> >>>>>>> On 2022/4/8 13:22, Dongliang Mu wrote:
> >>>>>>>> From: Dongliang Mu <mudongliangabcd@gmail.com>
> >>>>>>>>
> >>>>>>>> In f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or
> >>>>>>>> DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON(1) not matter
> >>>>>>>> blkaddr is in the range or not.
> >>>>>>>
> >>>>>>> If we run into the path where we invoke WARN_ON(1) in f2fs_is_valid_blkaddr(),
> >>>>>>> It means f2fs image may be broken, or there is a bug in f2fs.
> >>>>>>>
> >>>>>>> So, do you suffer any related issue in your environment?
> >>>>>>
> >>>>>> related issue? Can you explain a little?
> >>>>>>
> >>>>>> If you mean if this warning occurs, any other issues or crash
> >>>>>
> >>>>> I mean have you seen any warning info printed in the path of
> >>>>> f2fs_is_valid_blkaddr() before applying this patch, and if so, w/ what
> >>>>> reproducer? or you just figure out this patch from perspective of code
> >>>>> review?
> >>>>
> >>>> Yes, I have seen both warning information from Syzbot [1] and my local
> >>>> syzkaller instance.
> >>>>
> >>>> In f2fs_is_valid_blkaddr, if the following condition is satisfied,
> >>>> i.e., blkaddr is not in the right range [2], it will directly invoke
> >>>> one WARN_ON.
> >>>>
> >>>> if (unlikely(blkaddr >= MAX_BLKADDR(sbi) ||
> >>>> blkaddr < MAIN_BLKADDR(sbi))) {
> >>>>
> >>>> This is the case on Syzbot.
> >>>>
> >>>> Otherwise, it will jump into __is_bitmap_valid. And if the following
> >>>> condition is satisfied [3], it will trigger another WARN_ON.
> >>>>
> >>>> exist = f2fs_test_bit(offset, se->cur_valid_map);
> >>>> if (!exist && type == DATA_GENERIC_ENHANCE) {
> >>>>
> >>>> This appears in my local syzbot instance, but unfortunately it does
> >>>> not get any reproducer.
> >>>
> >>> Oh, it occurs in syzbot test, I guess it is possible that f2fs prints such
> >>> warning info after blkaddr of node/data block was fuzzed to invalid one.
> >>>
> >>> I prefer to keep WARN_ON() to catch more info of bugs found by non-fuzzed
> >>> type test.
> >>>
> >>> Thoughts?
> >>
> >> I am fine with both options. I can remove the WARN_ON in my local
> >> syzkaller instance and continue fuzzing Linux kernel.
> >>
> >> +Dmitry Vyukov how do you think? If WARN_ON is kept, this crash will
> >> occur on Syzbot from time to time.
> >
> > WARN_ON is for kernel bugs; please refer to the documentation in
> > include/asm-generic/bug.h. If this is a kernel bug, then the kernel bug needs
> > to be fixed. Otherwise, the WARN_ON needs to be removed.
>
> Alright, so how about using dump_stack() instead as suggested in doc?
I agree. Let's change WARN_ON to dump_stack().
>
> Thanks,
>
> >
> > - Eric
^ permalink raw reply [flat|nested] 20+ messages in thread