From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C241C433EF for ; Sun, 12 Dec 2021 09:15:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57A9B6B0071; Sun, 12 Dec 2021 04:15:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 52AE76B0073; Sun, 12 Dec 2021 04:15:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41A946B0074; Sun, 12 Dec 2021 04:15:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay040.a.hostedemail.com [64.99.140.40]) by kanga.kvack.org (Postfix) with ESMTP id 33B996B0071 for ; Sun, 12 Dec 2021 04:15:18 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0B3DD21B04 for ; Sun, 12 Dec 2021 09:15:08 +0000 (UTC) X-FDA: 78908583054.02.26838EC Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf27.hostedemail.com (Postfix) with ESMTP id 3B33740005 for ; Sun, 12 Dec 2021 09:15:07 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 75A2DB80B90; Sun, 12 Dec 2021 09:15:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7660C341C6; Sun, 12 Dec 2021 09:15:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639300504; bh=vLxxgiN0imWkT8KfiHgu08g5fJXl0/viq5uHLPUJ5SM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=QFlQM4qMyz1cklOPUeW6tPx2tCzGaG/5zH6dwDEWR1a3ZnitKeiHEdoPR/k3GdIx9 xtJi28g109rkIDdCZDJGr4mmqgu+wjV5D9GBplCyehOPPQSys8pYWZNj5R+MKzk8/2 rhzvoIbjz4BO4NdtudZ+ImeZZiEPInspxOaP8sfxdH1oJl63oOBOpKiaTVpXovCbvz iRb1Gr+1k+Ijdx+ayKvQIbaIaB056wQDuOl2LmsXn3zGNRKJ0hUtQKrJ55uoaN4LTM QrN7Axv7z9NnW7VojO2VCZprEh/n4//KuVXdT8GwCtZtFIgsi38pRYWPw8N4+hWUHS hMUCc4bV9qcHA== Message-ID: <51598d4d-0136-4a41-6b06-fbd7221ffd0e@kernel.org> Date: Sun, 12 Dec 2021 17:15:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty Content-Language: en-US To: Jaegeuk Kim , Matthew Wilcox Cc: syzbot , syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mm@kvack.org, Andrew Morton References: <0000000000005f297e05d24f05f6@google.com> <20211206175631.5d0c3caefa96f0479f0fc2e8@linux-foundation.org> From: Chao Yu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3B33740005 X-Stat-Signature: eqbocgc4gwwnj7auzqn7gaf9u7fdcdgy Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QFlQM4qM; spf=pass (imf27.hostedemail.com: domain of chao@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=chao@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1639300507-386179 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2021/12/8 6:10, Jaegeuk Kim wrote: > On 12/07, Matthew Wilcox wrote: >> On Tue, Dec 07, 2021 at 01:39:06PM -0800, Jaegeuk Kim wrote: >>> On 12/07, Matthew Wilcox wrote: >>>>>> Call Trace: >>>>>> >>>>>> folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 >>>> >>>> if (likely(mapping)) { >>>> ... >>>> if (folio_test_reclaim(folio)) >>>> folio_clear_reclaim(folio); >>>> return mapping->a_ops->set_page_dirty(&folio->page); >>>> >>>> how do we get to a NULL ->set_page_dirty for a metadata page's >>>> mapping->a_ops? This is definitely an f2fs expert question. >>> >>> I can't find anything in f2fs, since that page was got by f2fs_grab_meta_page >>> along with grab_cache_page() that we never unlocked it. >>> >>> 40 struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index) >>> 41 { >>> 42 struct address_space *mapping = META_MAPPING(sbi); >>> 43 struct page *page; >>> 44 repeat: >>> 45 page = f2fs_grab_cache_page(mapping, index, false); >>> >>> -> grab_cache_page(mapping, index); >>> >>> 46 if (!page) { >>> 47 cond_resched(); >>> 48 goto repeat; >>> 49 } >>> 50 f2fs_wait_on_page_writeback(page, META, true, true); >>> 51 if (!PageUptodate(page)) >>> 52 SetPageUptodate(page); >>> 53 return page; >>> 54 } >>> >>> >>> Suspecting something in folio wrt folio_mapping()? >>> >>> 81 bool set_page_dirty(struct page *page) >>> 82 { >>> 83 return folio_mark_dirty(page_folio(page)); >>> 84 } >> >> ... huh? How could folio_mapping() be getting this wrong? > > Dunno. > >> page_folio() does the same thing as compound_head() -- as far as I know >> you don't use compound pages for f2fs metadata, so this basically just >> casts the page to a struct folio. >> >> folio_mapping() is just like the old page_mapping() (see commit >> 2f52578f9c64). Unless you've done something like set the swapcache >> bit on your metadata page, it's just going to return folio->mapping >> (ie the same as page->mapping). > > Hmm, I've never seen this call stack before, so simply started to suspect > folio. I'm afraid this is a f2fs bug... :( folio wasn't merged at the first report time (5.14-rc2). https://syzkaller.appspot.com/bug?extid=07ff38c9c93ca170de07 I doubt the direct reason of panic may be the same as the one of bug reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215231 However, I still can't figure out why meta_inode's a_ops will change to f2fs_meta_aops. Thanks, > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel