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 8DB6BC47258 for ; Sat, 20 Jan 2024 06:47:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4ACF6B0072; Sat, 20 Jan 2024 01:47:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AFBE16B0074; Sat, 20 Jan 2024 01:47:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E9346B0075; Sat, 20 Jan 2024 01:47:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8FECA6B0072 for ; Sat, 20 Jan 2024 01:47:16 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 56474140822 for ; Sat, 20 Jan 2024 06:47:16 +0000 (UTC) X-FDA: 81698757672.18.4062B72 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf21.hostedemail.com (Postfix) with ESMTP id 08B521C000C for ; Sat, 20 Jan 2024 06:47:12 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf21.hostedemail.com: domain of zhangpeng362@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=zhangpeng362@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705733234; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vCeraLHrxR+bYf1EAxbKKL3EZ15AdA9jD/fhtsVbFeI=; b=s4/KMe7TA6IAU4SCA7R22KJ66xBsd9LGkd4Bk/SZy9dZKp2OZ2njtvTnAwZwlEI4srAmoF dUw0j80OK8DsfdiXHj6VlXB5gZgEW0zbhE32tepbmbG6YrPaqqAiH/aSr9qdZqU1hlQWaL XRFJ9kq4PphfuZMfJwB38yOkstza/VI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf21.hostedemail.com: domain of zhangpeng362@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=zhangpeng362@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705733234; a=rsa-sha256; cv=none; b=DJxKwGLhXDoCbVxARLq4X9aysNVEky+uiGCeArV84b/SRKaHTGAzmVptvDt7OqpGYBUrcp UJn8J7Hqa/bcMyIC1gpMuvePZPQaBZ0UvxvxbZEkLLsuikfxwQo4NOGMH0ZmrqNCRykaSG TIxDM7f89++BNQsUFUr9AkKsGG0PBGg= Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4TH6T755BQz1xmRW; Sat, 20 Jan 2024 14:46:19 +0800 (CST) Received: from kwepemm600020.china.huawei.com (unknown [7.193.23.147]) by mail.maildlp.com (Postfix) with ESMTPS id A238814011B; Sat, 20 Jan 2024 14:46:52 +0800 (CST) Received: from [10.174.179.160] (10.174.179.160) by kwepemm600020.china.huawei.com (7.193.23.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Sat, 20 Jan 2024 14:46:51 +0800 Message-ID: <5106a58e-04da-372a-b836-9d3d0bd2507b@huawei.com> Date: Sat, 20 Jan 2024 14:46:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [RFC PATCH] filemap: add mapping_mapped check in filemap_unaccount_folio() Content-Language: en-US To: Matthew Wilcox CC: , , , , , , , , , , References: <20240119092024.193066-1-zhangpeng362@huawei.com> From: "zhangpeng (AS)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.160] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm600020.china.huawei.com (7.193.23.147) X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 08B521C000C X-Stat-Signature: 7ogkpe155bh94pifgyqhw48zgon8cnbg X-Rspam-User: X-HE-Tag: 1705733232-243455 X-HE-Meta: U2FsdGVkX19CllYZ8m9I6TqcBOEH3L/ev4KS+dDEqszpMnYdH1cUOC3m3KZMEQMquR0bSBLzHnsdpcBpeljrAJb+B346cckzqvDAyaoLvv66Wi3ZIXMxOiQCPKW8OSs5Er1ReMd2o6i+oGGHoqLpTgA5WL1sNroNdpWrvZCttOJ/gglAYSUo+Q3HQBPIVJl2SsYLn5Ms1rOADUl9ghaThJ2830QeJaWPo7UH/MYa6tlNlQEVCp5lXY01+dCw7hFtNz/XuA3KGKM1c0lSBWLXo0B1w2aFBD1YniHd0uvj17KeRJMjm1aiEuTYSVWoJBP94BJqMbAw/QNwY7f809/TD6fEF5kfZcA65St9URgwvpklyJUBEP368oqGIXpZ2nrJ1ur3rxpU6Px4oeuTLgqyaVfq72e0qkCdihVGqnctfZlI3AB7aQjZAXROE4QrSsra34UR0MtuLVP8PEh4TCLfYnv9EtIIModvjx5Olnqi5YbXgEEUkQ0vZWZStsE7Ndb7ioh+V4JyywyE/PKbZcDatoV28JrYotjIdQDvfRRt1VWiIpdPSg5JehIBiTOe64+Qe7PZKKb6W4pw8ezWtPnVohynjSuN2cr+8XQHp9nWLkbtReIamjrlk8qomtCOmpvM/bjRuw9gagYnOSJXUBVsdJWXtclrrjfMshCZ5iiLxc5RH/3BlI5d9gDDzUZ5YijUqV4aGRb2qQr0Cv3Pd2HV4cKZYYKpsis3lRI7MuVymlhEhL7YAz/JnU45vqrpwAjg2rHCsDJp2HKJ1lZ79Jkw2zGL2uWA2ktdkHZhIZvE4tDKykUgLASOarJM5wT6D5noii3XySYVhNwWaLkb2eZK16w/qVzFOAExPrZlzWV3hqsZRA11KU6jmX8F8ROf74vDYZqVJqdK5ct+HOxzivXojGUoSQCPpVFyAonCDSfckAoA89bsURpcAOQLgkJiBCzBPXAJj4FbsMm/YO4+9Kq 4mwi0awN hdtTkZaIYVQEGt7QoveFUmcveaKo8fjWy/Mdl4Yzqnd0FTg5NPDB3/+AgoJodRsUrcGTdhFOs+Kjkyc8Iu/6NZHVWVxRUDG9oscD2B7TKUQlDBisGjVcyFCq+JQfLuZhqyesNPmT5Gxu69jZRqDv+fS7GaR3qJzNPFlgklhPG2+PYUyFPzRhDvPGeHQ== 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 2024/1/19 21:40, Matthew Wilcox wrote: > On Fri, Jan 19, 2024 at 05:20:24PM +0800, Peng Zhang wrote: >> Recently, we discovered a syzkaller issue that triggers >> VM_BUG_ON_FOLIO in filemap_unaccount_folio() with CONFIG_DEBUG_VM >> enabled, or bad page without CONFIG_DEBUG_VM. >> >> The specific scenarios are as follows: >> (1) mmap: Use socket fd to create a TCP VMA. >> (2) open(O_CREAT) + fallocate + sendfile: Read the ext4 file and create >> the page cache. The mapping of the page cache is ext4 inode->i_mapping. >> Send the ext4 page cache to the socket fd through sendfile. >> (3) getsockopt TCP_ZEROCOPY_RECEIVE: Receive the ext4 page cache and use >> vm_insert_pages() to insert the ext4 page cache to the TCP VMA. In this >> case, mapcount changes from - 1 to 0. The page cache mapping is ext4 >> inode->i_mapping, but the VMA of the page cache is the TCP VMA and >> folio->mapping->i_mmap is empty. > I think this is the bug. We shouldn't be incrementing the mapcount > in this scenario. Assuming we want to support doing this at all and > we don't want to include something like ... > > if (folio->mapping) { > if (folio->mapping != vma->vm_file->f_mapping) > return -EINVAL; > if (page_to_pgoff(page) != linear_page_index(vma, address)) > return -EINVAL; > } > > But maybe there's a reason for networking needing to map pages in this > scenario? Agreed, and I'm also curious why. >> (4) open(O_TRUNC): Deletes the ext4 page cache. In this case, the page >> cache is still in the xarray tree of mapping->i_pages and these page >> cache should also be deleted. However, folio->mapping->i_mmap is empty. >> Therefore, truncate_cleanup_folio()->unmap_mapping_folio() can't unmap >> i_mmap tree. In filemap_unaccount_folio(), the mapcount of the folio is >> 0, causing BUG ON. >> >> Syz log that can be used to reproduce the issue: >> r3 = socket$inet_tcp(0x2, 0x1, 0x0) >> mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) >> r4 = socket$inet_tcp(0x2, 0x1, 0x0) >> bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) >> connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) >> r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', >> 0x181e42, 0x0) >> fallocate(r5, 0x0, 0x0, 0x85b8) >> sendfile(r4, r5, 0x0, 0x8ba0) >> getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, >> &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, >> 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) >> r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', >> 0x181e42, 0x0) >> >> In the current TCP zerocopy scenario, folio will be released normally . >> When the process exits, if the page cache is truncated before the >> process exits, BUG ON or Bad page occurs, which does not meet the >> expectation. >> To fix this issue, the mapping_mapped() check is added to >> filemap_unaccount_folio(). In addition, to reduce the impact on >> performance, no lock is added when mapping_mapped() is checked. > NAK this patch, you're just preventing the assertion from firing. > I think there's a deeper problem here. -- Best Regards, Peng