Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr

[Dongliang Mu]

On Mon, Apr 11, 2022 at 11:10 AM Chao Yu <chao@xxxxxxxxxx> wrote:
>
> On 2022/4/9 14:42, Dongliang Mu wrote:
> > On Sat, Apr 9, 2022 at 11:46 AM Chao Yu <chao@xxxxxxxxxx> wrote:
> >>
> >> On 2022/4/9 9:34, Dongliang Mu wrote:
> >>> On Sat, Apr 9, 2022 at 8:27 AM Chao Yu <chao@xxxxxxxxxx> wrote:
> >>>>
> >>>> On 2022/4/8 13:22, Dongliang Mu wrote:
> >>>>> From: Dongliang Mu <mudongliangabcd@xxxxxxxxx>
> >>>>>
> >>>>> 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&amp;data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=UVSSS9IknYLJHzqqJAN5HmPgJ8GNczvi6%2FuQf2n3vlY%3D&amp;reserved=0
> > [2] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Ffs%2Ff2fs%2Fcheckpoint.c%23L187&amp;data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Sf%2Bx8WCAXf5c4%2Bins46saTsTN5uNTrnIceAP3oCWnQw%3D&amp;reserved=0
> > [3] https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Ffs%2Ff2fs%2Fcheckpoint.c%23L135&amp;data=04%7C01%7Cchao.yu%40oppo.com%7Cff92e63621b24fc75a4908da19f45860%7Cf1905eb1c35341c5951662b4a54b5ee6%7C0%7C0%7C637850834521060840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Ly%2FBL5oFAWZmXwbN6TaYCExroDE8%2Fsli1alaJwR4wvU%3D&amp;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@xxxxxxxxxxxxxxxxxxxxxxxxx
> >>>>> Signed-off-by: Dongliang Mu <mudongliangabcd@xxxxxxxxx>
> >>>>> ---
> >>>>>     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@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel