Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1793590pxu; Thu, 8 Oct 2020 22:57:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvpo0+4vT75t70QyLUJuZJFta0g2Mc6gWJEFsOpZb/09Ro2MFs6oR0npru2uf3J+SKicgB X-Received: by 2002:a17:906:394:: with SMTP id b20mr12283227eja.513.1602223071599; Thu, 08 Oct 2020 22:57:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602223071; cv=none; d=google.com; s=arc-20160816; b=buKLVbiPwz0Keis5puK+OjMe4lMg7cdIbZo/5Zvj7p/+54i+OTfhLaOY1Y46TL+2pN li1nSWRw1Kjynv2C+ppSS1xpKHmFY8P/mC4vIJEpRBlMT9YvGe/r5FFr7ZKq2OqCI4nj zYvqDDHV1vQHugzic7yuNRb3KEtt0UTKz9dtKjj+nVmc4smEt25DZlDGhln4HCtpHTBY VaDad3k0a3JWtIQ8K+X0Dd5rlhr7kqAsA5EfQudFQYSsDLY9WhoI7+V0yjyNRFl6RkV/ sfSpyN2MFZ/03Lb6gqCnNCvpAiq3zyirnVBHyhOJ9JGYmeKnK9lvs2+chkOGlB5ojwdR Rf9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=KhjRnPtxOYTQTFlhE/kkNuyXd9lWh0WoNq5+IFjb/ZM=; b=ijM3Lbf5Jw8YQlOeMLscEv6mRmx3OQvksBqD9r7xyQDWiE77hCkmo7Ut02kcrfadfd Wq4iNFZcQCldtUNPInoiEp4rvUMJrOA8VhP0KVWUtg6jo2gEvaTQEgCVqIaTGXn5nR4V Q+f91X87p+B8m5BFN9OonFzvysuhNou00L76ghyqYOLIDXAmA0TKT/SBMTMASYrxmIZG I1I6tJrtEyom8XTA5kRe+jd7fLGx+G8Iivar8gIfQjON91bF+fjhWtVvYKev6+eLfwuL JkIAWgG1PPwKi1ePHRxj0hEyl6pCPusWVQ58pSLjgynAHX6X+hAZAI9t0h+1cSBI4CZc V32w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d17si5776168edp.500.2020.10.08.22.57.28; Thu, 08 Oct 2020 22:57:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730568AbgJIBmG (ORCPT + 99 others); Thu, 8 Oct 2020 21:42:06 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:51718 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727313AbgJIBmF (ORCPT ); Thu, 8 Oct 2020 21:42:05 -0400 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 2F9D01D630E861D9C3E1; Fri, 9 Oct 2020 09:42:04 +0800 (CST) Received: from [10.136.114.67] (10.136.114.67) by smtp.huawei.com (10.3.19.212) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 9 Oct 2020 09:42:03 +0800 Subject: Re: [f2fs-dev] [f2fs bug] infinite loop in f2fs_get_meta_page_nofail() To: , Eric Biggers CC: , , , References: <000000000000432c5405b1113296@google.com> <20201007213253.GD1530638@gmail.com> <20201007215305.GA714500@google.com> From: Chao Yu Message-ID: Date: Fri, 9 Oct 2020 09:42:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20201007215305.GA714500@google.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.136.114.67] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/10/8 5:53, jaegeuk@kernel.org wrote: > On 10/07, Eric Biggers wrote: >> [moved linux-fsdevel to Bcc] >> >> On Wed, Oct 07, 2020 at 02:18:19AM -0700, syzbot wrote: >>> Hello, >>> >>> syzbot found the following issue on: >>> >>> HEAD commit: a804ab08 Add linux-next specific files for 20201006 >>> git tree: linux-next >>> console output: https://syzkaller.appspot.com/x/log.txt?x=17fe30bf900000 >>> kernel config: https://syzkaller.appspot.com/x/.config?x=26c1b4cc4a62ccb >>> dashboard link: https://syzkaller.appspot.com/bug?extid=ee250ac8137be41d7b13 >>> compiler: gcc (GCC) 10.1.0-syz 20200507 >>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1336413b900000 >>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12f7392b900000 >>> >>> The issue was bisected to: >>> >>> commit eede846af512572b1f30b34f9889d7df64c017d4 >>> Author: Jaegeuk Kim >>> Date: Fri Oct 2 21:17:35 2020 +0000 >>> >>> f2fs: f2fs_get_meta_page_nofail should not be failed >>> >> >> Jaegeuk, it looks like the loop you added in the above commit doesn't terminate >> if the requested page is beyond the end of the device. > > Yes, that will go infinite loop. Otherwise, it will trigger a panic during > the device reboot. Let me think how to avoid that before trying to get the > wrong lba access. Delivering f2fs_get_sum_page()'s return value needs a lot of codes change, I think we can just zeroing sum_page in error case, as we have already shutdown f2fs via calling f2fs_stop_checkpoint(), then f2fs_cp_error() will stop all updates to filesystem data including summary pages. Thoughts? Thanks, > >> >> - Eric > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > . >