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 72621C433F5 for ; Fri, 22 Apr 2022 18:30:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB1E76B0073; Fri, 22 Apr 2022 14:30:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A60526B0074; Fri, 22 Apr 2022 14:30:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 929E76B0075; Fri, 22 Apr 2022 14:30:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 8174C6B0073 for ; Fri, 22 Apr 2022 14:30:27 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 554D980BC5 for ; Fri, 22 Apr 2022 18:30:27 +0000 (UTC) X-FDA: 79385355294.11.E433A19 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id 353A918003E for ; Fri, 22 Apr 2022 18:30:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=1+/SezKGzMa2gnYmR8YMQNvrpOnLCVM89OTXqKWDzhs=; b=oEro949fGP54rYhWze+ktQj1CX 1wqxWAPrnzs46IEeO3i+tVzFM0JRFFIhE1Fr+L+ed+mIJsv7HIxh1E5cTbQLso4bRrfHGvyBC53ej q+4RdtSq7bCh1amvKXP2z9oOgxevFB6X6pcg9FhXxqtAy4s/WfnA9N5qZzGvurSNuKSHCDzA47Jv4 J8Owl4cxZQNk3qXKIqEJiGD1a335I2hIPiEqua0FLPueUATY37Yqf6PFo71ZcmpVcY8Ou8juVAMfR Rrit/51iOsUP0QsW0aXt9wxbPTYIqIpxV+0FRaeghfsx3MyEGpQHytlu7EDCwDyRWgW8vZNM1SYuc rKz4IDSA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhy2h-006Ja9-Q8; Fri, 22 Apr 2022 18:30:07 +0000 Date: Fri, 22 Apr 2022 19:30:07 +0100 From: Matthew Wilcox To: syzbot Cc: akpm@linux-foundation.org, dhowells@redhat.com, hughd@google.com, kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, vbabka@suse.cz, william.kucharski@oracle.com Subject: Re: [syzbot] kernel BUG in __filemap_get_folio Message-ID: References: <000000000000625fa705dd1802e3@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: g78p8dhssckgzhwdpxnpwhwy18trefjt X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 353A918003E X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oEro949f; dmarc=none; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-HE-Tag: 1650652223-571435 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 Thu, Apr 21, 2022 at 09:21:34PM +0100, Matthew Wilcox wrote: > I wish I knew which 'index' we were looking up. I'll try reproducing it > locally so I can print that out too. I can't reproduce it locally because the OOM killer says I don't have enough RAM. That's with giving 4GB to the VM. If I give more than 4GB to the VM, my laptop is insufficiently studly, and the host OOM killer takes out qemu instead ;-P > My suspicion is that there's a race where the folio is split during the > lookup, and the bug is really in mapping_get_entry(). The folio->index > is weird though; if this was the explanation, I'd expect it to find a > page at a multiple of 512 or at least a multiple of 64. I think I have an explanation (from thinking really hard, rather than testing). Before we call xas_split(), the tree looks like this: node (shift=6) -> page (index 0) -> sibling of 0 -> sibling of 0 -> sibling of 0 -> sibling of 0 -> sibling of 0 -> sibling of 0 -> sibling of 0 -> page (index 0x200) -> sibling of 8 -> sibling of 8 -> sibling of 8 -> sibling of 8 -> sibling of 8 -> sibling of 8 -> sibling of 8 -> sibling of 8 Then we split the page at index 0x200. Simultaneously, we try to load the page at index 0x274 (or 2b4 or 2f4 or ... 3f4). The load picks up the sibling entry at offset 9 (0x274 >> 6), which says to refer to the entry at offset 8. But by the time it gets the entry at offset 8, the split has replaced the compound page at index 0x200 with a node that points to pages at indices 0x200-0x23f. Solving it on the split side is possible, but I think it's easier to solve on the load side. I have a patch, it seems to work; let's see what syzbot thinks of it: #syz test: git://git.infradead.org/users/willy/xarray.git main