From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp134-25.sina.com.cn (smtp134-25.sina.com.cn [180.149.134.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAD941854 for ; Sat, 11 Jan 2025 01:02:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=180.149.134.25 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736557330; cv=none; b=nEVV9S+hLfIFav15vtYbfN4u6GhApgLvtEIsYb6s17FASf2uiBDwGiMZZa3TLBJV8lfq/6r2h9xenB3FStXCxCafFa27K98SKy5STZiKxLigBJ3uB262E07QyT54t6SeZhPwpTYn12Mm5pGUY3AOVTLDRKuUcdg8iIP3fFajkLc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736557330; c=relaxed/simple; bh=jD2C8QmdZXOPFZCQKniVM7qysmAVBgI/LkLkOZV+wwo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JYngSsln0Grl7EwOvTWKDwTYht/znvDIxC44s0ZOZbuFCaAvwxARe1EGg5p2+ifGs1zRjUrwZVdaCoE9+mcTiLOaDpS1hBGO/CU/wFEmM0MD+6xFv4vewz/XUetQqm/hVb9VZWWno4jeS01LeOhAPIke58msyguZ2s2EHpgVssQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; arc=none smtp.client-ip=180.149.134.25 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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 Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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/