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 A2867E77188 for ; Sat, 11 Jan 2025 01:01:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE1356B00A9; Fri, 10 Jan 2025 20:01:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E90136B00AA; Fri, 10 Jan 2025 20:01:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7EFC6B00AB; Fri, 10 Jan 2025 20:01:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BCAB66B00A9 for ; Fri, 10 Jan 2025 20:01:25 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 32D40140FBC for ; Sat, 11 Jan 2025 01:01:25 +0000 (UTC) X-FDA: 82993367730.22.D593F33 Received: from smtp134-32.sina.com.cn (smtp134-32.sina.com.cn [180.149.134.32]) by imf21.hostedemail.com (Postfix) with ESMTP id 2082D1C000A for ; Sat, 11 Jan 2025 01:01:21 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.hostedemail.com: domain of hdanton@sina.com designates 180.149.134.32 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736557283; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UgdT3eV+DWtk5YqHVW0XEUmtrd7ANFbuMr93CO9HFqw=; b=JRzCPMmPyCi+mETLxu89cRNtWJzHPlYUzsDDz5sinXvSqEvdacVf5/tkZlNBM8h7xARipw rysM2RhdisH1vXnRGfONgWvc2XE1bTRIleH9d24Py7OPkhXoZmSqQmSadxq831h6VAKsUs zrv/QSXPn29BdqnbE4AqhQe0gJlFGAA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736557283; a=rsa-sha256; cv=none; b=hhWCZjumq1ZjWr5hUdjxMYYW511uXKzv1zW46NjhP71RcM/47BvZPBtHYXfvq0MwcJe1ql pkClnNSYH8xuXUIIlUrLGRK+8QNyBqbzUMJxX7s5E605A77JqbbwrMdA26De/7N9GmPR+g uobA1xSuc0sddnA2aDyTFoE32h1f+nI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.hostedemail.com: domain of hdanton@sina.com designates 180.149.134.32 as permitted sender) smtp.mailfrom=hdanton@sina.com X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.118.71.135]) by sina.com (10.185.250.21) with ESMTP id 6781C2D800005ECE; Sat, 11 Jan 2025 09:01:15 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 036903408299 X-SMAIL-UIID: 39F2FBC09C964E65858D31E270C12025-20250111-090116-1 From: Hillf Danton To: David Hildenbrand Cc: syzbot , linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [mm?] WARNING in __folio_rmap_sanity_checks (2) Date: Sat, 11 Jan 2025 09:00:43 +0800 Message-ID: <20250111010103.1615-1-hdanton@sina.com> In-Reply-To: References: <20241231084108.1146-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 2082D1C000A X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: 5ukxzgmd4ac576iig95eeiningqoju13 X-HE-Tag: 1736557281-104094 X-HE-Meta: U2FsdGVkX1/Rt5mXs+EqzZQIbkOP4oeOMfmTqyXJvvnfbo50GCra3JmnRvjB1ZWuFmMYWNqoupAE+POjaUqzw+Oq7dfECJFcfpGTOjvodchUZcGPHC3VBy5BGtSkM4KeKkdML2r2paLjPKschopLYtjnDo3LeIgBUceb1Q8CLyKxP4l2aBea6NcOENvpI00LEIsVcMRjNXBRLsfM8sBWnHJKYs9rycxFYL3CEYU7XxESuMZBoayNI1F884DbVDKL0Z85CCOAU8Ln8w8WFc2k6hQ8oQdxZtuSJefRYxWHYL1YBYY48kJk11QfZguAbWn0Va5KLBdHtElEaO2tLVcCkuVo+Mw5H3x3P3bAWn9J218qr/AbpgDlzMsKCHGo4lwHl+CS28CYa9xCzOc9US2rowrddFY5t99ZjNIqwV5eWYP5IoZojYkbvev25a6SiMqeV/Bl0UoFicWOCzjMj3WOP/Tkz1ZlunWN+H4+zUhDnTS4Aqqk5YDibZgj3r9h/RXtyL5y2bC7H0EKD14czQ0/TKGJob2q2XS+KYiNnDAXxC0gWzcXLUahx88OH8XfXcEzTO7HRa6AIvg07Mz5j9hEXvU9nQ65rFZ1kQ3Zx4LXlckHnarufbPLhq43XMPoopOKWgrZZlm6vmZSOraDw3xZWOoJmMl26jb9NsLUjhLNaxAaJkXFP/H+ukeTmKpu1FnGa8yfxKpQemrzoe8bkCN2o+et1oieosXfh9FPUylR/zAp7j6ZbhUlhbV6T3BQxfbQ7UzFZ9P0jF33e+zJ6Scn+qWroGaAcJZmsvIOeiUZDXw3Irh+H0qf5qOsdItlfG1dy76E2FlobjKUTeszDa541+VUQA2/u3SpLPa8FrHc9QwduFgN7fD+j54igUr14SchzV5OOecNlE59lYzL97S+HIMOfunPhrT1mOIpNXYsCQeoWby6La+7ceXPSsUsKGrU1Ct+VHRue16kG/QU8jY HjAlFs8B wkfU42je2lMdNHHZiVuRAKVlL44cHou4TO8TdEzOVIDQlu7zrAjaKVmory8/heb0RTgRRW+A6nGTLm1kGrqouLR9wz2a6kUaK4iavxGgxQwxMUku54hYxbBn9CYAxlKkpRRkNj7wKowQ/yXRxgdHkiN9G/lm5C29/cyDvMXxnqyfMbe73xoBEVT91imUov2VggVfyh/RarOnZYzRK2UzNHEYQyMl4GHvGSM2sUXsTjYSoZPZYNE69+Re++Btj7VvML1nI+7SjU3Nx4O9ROM0DK4lkO2JbATjdK0oRgRaI+rF4TRZw1/OOkA63tR0n6sYKchxRk10knrSBowp/WF1uld7lk6lNJ0kjEQoWFuOmBZ4V5x1BY2Zbfh3KyiiOb77XzbGmcsccwmkYd5JjRgGwHp1i2ai1ab4X7I5ae8DdgMzZAtOmf0698QWMla8QLx/dsXovDpM2VjVghAhrWxcfMgBo5A== 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: List-Subscribe: List-Unsubscribe: On Fri, 10 Jan 2025 17:35:25 +0100 David Hildenbrand > On 31.12.24 09:41, Hillf Danton wrote: > > On Fri, 27 Dec 2024 20:56:21 -0800 > >> syzbot has found a reproducer for the following issue on: > >> > >> HEAD commit: 8155b4ef3466 Add linux-next specific files for 20241220 > >> git tree: linux-next > >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1652fadf980000 > > > > #syz test > > > > --- x/mm/filemap.c > > +++ y/mm/filemap.c > > @@ -3636,6 +3636,10 @@ static vm_fault_t filemap_map_folio_rang > > continue; > > skip: > > if (count) { > > + for (unsigned int i = 0; i < count; i++) { > > + if (page_folio(page + i) != folio) > > + goto out; > > + } > > IIRC, count <= nr_pages. Wouldn't that mean that we somehow pass in > nr_pages that already exceeds the given folio+start? > > When I last looked at this, I was not able to spot the error in the > caller :( > This is a debug patch at the first place, and this hunk overlaps with the next one. > > set_pte_range(vmf, folio, page, count, addr); > > *rss += count; > > folio_ref_add(folio, count); > > @@ -3658,6 +3662,7 @@ skip: > > ret = VM_FAULT_NOPAGE; > > } > > > > +out: > > vmf->pte = old_ptep; > > > > return ret; > > @@ -3702,7 +3707,7 @@ vm_fault_t filemap_map_pages(struct vm_f > > struct file *file = vma->vm_file; > > struct address_space *mapping = file->f_mapping; > > pgoff_t file_end, last_pgoff = start_pgoff; > > - unsigned long addr; > > + unsigned long addr, pmd_end; > > XA_STATE(xas, &mapping->i_pages, start_pgoff); > > struct folio *folio; > > vm_fault_t ret = 0; > > @@ -3731,6 +3736,12 @@ vm_fault_t filemap_map_pages(struct vm_f > > if (end_pgoff > file_end) > > end_pgoff = file_end; > > > > + /* make vmf->pte[x] valid */ > > + pmd_end = ALIGN(addr, PMD_SIZE); > > + pmd_end = (pmd_end - addr) >> PAGE_SHIFT; > > + if (end_pgoff - start_pgoff > pmd_end) > > + end_pgoff = start_pgoff + pmd_end; > > + > > do_fault_around() comments "This way it's easier to guarantee that we > don't cross page table boundaries." > > It does some magic with PTRS_PER_PTE. > > You're diff here seems to indicate that this is not the case? > > But it's rather surprising that we see these issues pop up just now in > -next. > Given double check [1], I am lean to thinking this is a simple OOB issue. [1] https://lore.kernel.org/all/6774eca1.050a0220.25abdd.09b2.GAE@google.com/