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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F576C11F64 for ; Thu, 1 Jul 2021 18:37:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 12EE061402 for ; Thu, 1 Jul 2021 18:37:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12EE061402 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7A84E8D02B2; Thu, 1 Jul 2021 14:37:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 758B28D0001; Thu, 1 Jul 2021 14:37:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D1C08D02B2; Thu, 1 Jul 2021 14:37:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) by kanga.kvack.org (Postfix) with ESMTP id 342B08D0001 for ; Thu, 1 Jul 2021 14:37:20 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id DE7EB18384092 for ; Thu, 1 Jul 2021 18:37:19 +0000 (UTC) X-FDA: 78314876598.17.AEC24F7 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf24.hostedemail.com (Postfix) with ESMTP id 7E985B0000A2 for ; Thu, 1 Jul 2021 18:37:19 +0000 (UTC) Received: by mail-ej1-f50.google.com with SMTP id c17so11955764ejk.13 for ; Thu, 01 Jul 2021 11:37:19 -0700 (PDT) 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=MgQKwoEBB404LDL6nzwNvU8qjp2O2EAi3/ZuC5D3Slc=; b=htlkR5jS8EpFN6R7dsROl/p62QsqU0Kw9OWK3at5uj4KFWBINwvZpQHlX8QGuDGC0P Kbz68HLDFX+4aEr5Hh0pGqWaPQeYDKx4/zuFqqL9I71Pv5XqjtchLwHmcd/xzcewl56A TOE+YJaFAiHOCPhfnLdry146N0NbnhI01qixs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MgQKwoEBB404LDL6nzwNvU8qjp2O2EAi3/ZuC5D3Slc=; b=Bv8LdescLdYvJrvvXW4DEfVfmcwF31QoHHXmHnbFlkCsoyKVqR7W6pjVm7WwVetQYd XNAxDhD8FjwwjdwCnU7g4IUypE+bH6AvhBPrjGsHNfkMboCUokX2t/Nxm7I+7eK5NNc8 3lrSPbTT0IlgHcT5o+PHV7ec6ktkoeaqUtOQ5t8ouw3OI4uOOBNn+dB2oUsPXIHFBd+H N06CI++ibl1qFjO1OduDZwbSu8UHn5xtIaUsEHXbfAj9zKXbwYa+lJ4n1rdgUZ9KUHRp dxyEkqE7gydKQNxu9evnJrhnhVnufZsU7Mm6Bjo8iTvps189ukWln0cJ1SCZELi29QnY mhsA== X-Gm-Message-State: AOAM533ft6x/AhYgeVAx/UfXCUrWVSbDv/tiMcaYNJw0bTEZi8BBjYca 9gFe3s10OKRg4YvYrxeCrNSNeXPlb8ZqdYLc2To= X-Google-Smtp-Source: ABdhPJzKh58ERLL0GdmGHPy596kqkIMKIMjhk1ynWnAc6D8XxHw2HHlAz81TQQg6cF8zpftaNuN0aw== X-Received: by 2002:a19:4c54:: with SMTP id z81mr736380lfa.28.1625164207872; Thu, 01 Jul 2021 11:30:07 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id h37sm41257lfv.85.2021.07.01.11.30.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Jul 2021 11:30:07 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id u13so13543602lfk.2 for ; Thu, 01 Jul 2021 11:30:06 -0700 (PDT) X-Received: by 2002:a05:6512:15a2:: with SMTP id bp34mr734975lfb.40.1625164206758; Thu, 01 Jul 2021 11:30:06 -0700 (PDT) MIME-Version: 1.0 References: <20210628193256.008961950a714730751c1423@linux-foundation.org> <20210629023959.4ZAFiI8oZ%akpm@linux-foundation.org> In-Reply-To: From: Linus Torvalds Date: Thu, 1 Jul 2021 11:29:50 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 128/192] mm: improve mprotect(R|W) efficiency on pages referenced once To: Peter Xu Cc: Andrew Morton , Andrea Arcangeli , Evgeniy Stepanov , Kostya Kortchinsky , Linux-MM , mm-commits@vger.kernel.org, Peter Collingbourne Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=htlkR5jS; spf=pass (imf24.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Stat-Signature: 44smcn9kjg4c466m4yf85wdxu51wcw5h X-Rspamd-Queue-Id: 7E985B0000A2 X-Rspamd-Server: rspam06 X-HE-Tag: 1625164639-505800 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 Wed, Jun 30, 2021 at 6:27 PM Peter Xu wrote: > > On Wed, Jun 30, 2021 at 11:03:25AM -0700, Linus Torvalds wrote: > > > > What about that page_count() test, for example: it has a comment, it > > looks obvious, but it's very different from what do_wp_page() does. So > > what happens if we have a page-out at the same time that turns that > > page into a swap cache page, and increments the page count? What about > > that race? Do we end up with a writable page that is shared with a > > swap cache entry? Is that ok? Why isn't it ok in the page fault case? > > That looks fine to me: when the race happens we must have checked page_count==1 > first and granted the write bit, then add_to_swap_cache() happens after the > page_count==1 check (as it takes another refcount, so >2 otherwise). Then it > also means unmap mappings should happen even after that point. If my above > understanding is correct, our newly installed pte will be zapped safely soon, > but of course after we release the pgtable lock in change_pte_range(). So if this is fine, then maybe we should just remove the page lock in the do_wp_page() path (and remove the PageKSM check while at it)? If it's not required by mprotect() to say "I can make the page writable directly", then it really shouldn't be required by the page fault path either. Which I'd love to do, and was really itching to do (it's a nasty lock), but I worried about it.. I'd hate to have mprotect do one thing, and page faulting do another thing, and not have some logic to why they have to be different. Linus