Messages in this thread | | | From | Dongliang Mu <> | Date | Mon, 11 Apr 2022 13:06:09 +0800 | Subject | Re: [f2fs-dev] [PATCH] fs: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr |
| |
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
| |