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 87ED2C433F5 for ; Thu, 20 Jan 2022 15:37:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE12B6B00A1; Thu, 20 Jan 2022 10:37:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E69CB6B00A3; Thu, 20 Jan 2022 10:37:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0AA76B00A4; Thu, 20 Jan 2022 10:37:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id B917F6B00A1 for ; Thu, 20 Jan 2022 10:37:31 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7AF788249980 for ; Thu, 20 Jan 2022 15:37:31 +0000 (UTC) X-FDA: 79051069902.07.4CEA055 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf24.hostedemail.com (Postfix) with ESMTP id 2576E18005A for ; Thu, 20 Jan 2022 15:37:30 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id c24so28034492edy.4 for ; Thu, 20 Jan 2022 07:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aHr47Yn1aQ2oLbzKOLUIvoEfRNOv+H9Lzlr0T36vdYs=; b=c59rI5tTjPHQX5oara7rDAzHiToNlpr1xLa2EaLq0i8wxl8+7McWlcU1NWpJ1o9f7M Rzv5tsDhLIslBsZTPjvkwjCnJqLCKVQg5hiIN4TmnwsecLmmU187k6EiQXjnXEaWpCY2 jFJSpLN1Md1XWSm8oA5U2druh67WwyGzmvn4c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aHr47Yn1aQ2oLbzKOLUIvoEfRNOv+H9Lzlr0T36vdYs=; b=y13oAbfdGZSiA4HQ0Y7Mt+z/xsnXkFJ2rKED9DJ2tplM6ocHuGBTN60AkxomGk2qiR RkWXcLhDT6Yd5DOWuv/eRyt1Q2+60b5FHC8UOq9Tm/IRhzIPKMHWWns+zglAcAYwhDjN C4LuDNFdmBubKvjmZynKoa0Nkdr7HoQyKm8XqtwupbgYNQvEFxovsQFOQYQNXIoxgJhE PR3oTWphtxPA7wEvISeI4zpJSPQqok95NeB1A/OGluIaMz5XEW0wqddKqvQwY1ZG1EKY eNKs+eQZYVmWvA/vXHrC6VGXXDaWV/wbyTZxuIsaPcG+gbNVYza9BEIEEuIJ6ODkWkHa Udag== X-Gm-Message-State: AOAM5303uQH6bdAy24dtz11v/8u3OhXVQpLKglKO1HPKDBuR3+CmHifM xuSfxhAB0Mi6kwmYCYy8lZUpCugKK18Zxzc0 X-Google-Smtp-Source: ABdhPJxLY1R4NPPLkL8VRYcSgxLM7+cgP91vBwRvZ2Nq+H0UDcd+58ZhddI72z/0IZW4/WooScp0/w== X-Received: by 2002:a17:906:c14b:: with SMTP id dp11mr5912369ejc.7.1642693049505; Thu, 20 Jan 2022 07:37:29 -0800 (PST) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com. [209.85.128.52]) by smtp.gmail.com with ESMTPSA id p2sm1447164edy.73.2022.01.20.07.37.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Jan 2022 07:37:28 -0800 (PST) Received: by mail-wm1-f52.google.com with SMTP id o7-20020a05600c510700b00347e10f66d1so7310643wms.0 for ; Thu, 20 Jan 2022 07:37:27 -0800 (PST) X-Received: by 2002:adf:c74e:: with SMTP id b14mr34195514wrh.97.1642693047630; Thu, 20 Jan 2022 07:37:27 -0800 (PST) MIME-Version: 1.0 References: <20220113140318.11117-1-zhangliang5@huawei.com> <172ccfbb-7e24-db21-7d84-8c8d8c3805fd@redhat.com> <9cd7eee2-91fd-ddb8-e47d-e8585e5baa05@redhat.com> <747ff31c-6c9e-df6c-f14d-c43aa1c77b4a@redhat.com> In-Reply-To: From: Linus Torvalds Date: Thu, 20 Jan 2022 17:37:11 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page To: David Hildenbrand Cc: Matthew Wilcox , "zhangliang (AG)" , Andrew Morton , Linux-MM , Linux Kernel Mailing List , wangzhigang17@huawei.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 2576E18005A X-Stat-Signature: chrfj8irbmmhw7iwh16dj8kcunayrqio Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=c59rI5tT; spf=pass (imf24.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam07 X-HE-Tag: 1642693050-138097 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, Jan 20, 2022 at 5:26 PM David Hildenbrand wrote: > > So your claim is that read-only, PTE mapped pages are weird? How do you > come to that conclusion? > > If we adjust the THP reuse logic to split on additional references > (page_count() == 1) -- similarly as suggested by Linus to fix the CVE -- > we're going to end up with exactly that more frequently. If you write to a THP page that has page_count() elevated - presumably because of a fork() - then that COW is exactly what you want to happen. And presumably you want it to happen page-by-page. So I fail to see what the problem is. The *normal* THP case is that there hasn't been a fork, and there is no COW activity. That's the only thing worth trying to optimize for and worry about. If you do some kind of fork with huge-pages, and actually write to those pages (as opposed to just execve() in the child and wait in the parent), you only have yourself to blame. You *will* take COW faults, and you have to do it, and at that point spliting the THP in whoever did the COW is likely the right thing to do just to hope that you don't have to allocate a whole new hugepage. So it will cause new (small-page) allocations and copies. And yes, at that point, writes to the THP page will cause COW's for both sides as they both end up making that "split it" decision. Honestly, would anything else ever even make sense? If you care about THP performance, you make sure that the COW THP case simply never happens. Linus