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 4D6B2C433F5 for ; Fri, 14 Jan 2022 05:00:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B2376B0072; Fri, 14 Jan 2022 00:00:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 261EB6B0073; Fri, 14 Jan 2022 00:00:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12C056B0074; Fri, 14 Jan 2022 00:00:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 03CDF6B0072 for ; Fri, 14 Jan 2022 00:00:34 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A71AA82DCD1A for ; Fri, 14 Jan 2022 05:00:33 +0000 (UTC) X-FDA: 79027691946.31.41798F8 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf21.hostedemail.com (Postfix) with ESMTP id 895491C000D for ; Fri, 14 Jan 2022 05:00:32 +0000 (UTC) Received: from dggpemm500021.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4JZpxv5P0bzbjvy; Fri, 14 Jan 2022 12:59:47 +0800 (CST) Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm500021.china.huawei.com (7.185.36.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 14 Jan 2022 13:00:28 +0800 Received: from [10.174.185.129] (10.174.185.129) by dggpemm500003.china.huawei.com (7.185.36.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 14 Jan 2022 13:00:28 +0800 Message-ID: Date: Fri, 14 Jan 2022 13:00:27 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page Content-Language: en-US To: David Hildenbrand CC: Andrew Morton , Linux-MM , Linux Kernel Mailing List , , Matthew Wilcox , "Linus Torvalds" References: <20220113140318.11117-1-zhangliang5@huawei.com> <172ccfbb-7e24-db21-7d84-8c8d8c3805fd@redhat.com> From: "zhangliang (AG)" In-Reply-To: <172ccfbb-7e24-db21-7d84-8c8d8c3805fd@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.185.129] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500003.china.huawei.com (7.185.36.56) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 895491C000D X-Stat-Signature: qrj7esthquf9ipth3g3c459681r91tqt Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf21.hostedemail.com: domain of zhangliang5@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=zhangliang5@huawei.com X-HE-Tag: 1642136432-601232 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 2022/1/14 0:48, David Hildenbrand wrote: > On 13.01.22 17:37, Linus Torvalds wrote: >> On Thu, Jan 13, 2022 at 6:39 AM Matthew Wilcox wrote: >>> >>> Let's bring Linus in on this, but I think this reintroduces all of the >>> mapcount problems that we've been discussing recently. >>> >>> How about this as an alternative? >> >> No, at that point reuse_swap_page() is the better thing to do. >> >> Don't play games with page_count() (or even worse games with >> swap_count). The page count is only stable if it's 1. Any other value >> means that it can fluctuate due to concurrent lookups, some of which >> can be done locklessly under RCU. > > I'm pretty sure the patch as is will reintroduce the CVE. So I think in Actually, I wonder how reuse_swap_page() in this patch can reintroduce CVE, I think the invoking logic here is as same as that in do_swap_page(). So, could you give me some hint about this? Thanks :) > addition to the reuse_swap_page() check we need more. > > I'm wondering if we can get rid of the mapcount checks in > reuse_swap_page() and instead check for page_count() and swapcount only. > > We don't care if it's unstable in a sense than it will be bigger than > what we expect. In that case we COW as we would already do. > > Thoughts? > -- Best Regards, Liang Zhang