Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp269396rwb; Wed, 14 Dec 2022 17:12:11 -0800 (PST) X-Google-Smtp-Source: AA0mqf5gLJ7v/pZfcOt7qSAwhIEB4Amn9VWe+H3gIMeuG/o5Z3JNGw7qZmYttw/w9sCh+YiXpB5E X-Received: by 2002:a05:6402:d65:b0:46d:afb4:ef16 with SMTP id ec37-20020a0564020d6500b0046dafb4ef16mr22029219edb.42.1671066730736; Wed, 14 Dec 2022 17:12:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671066730; cv=none; d=google.com; s=arc-20160816; b=ELBqyU+KMXtPUlk3HIvHwddXIMdXEM3jN7tOFjU1uKndTrcAf1gaOWgbxQQm2N+pOv gE8Yw6E9GJOQ/UJsVrupx8bJjHzfXJJUvSu7C3MHEEPZH6hCIIEHkRAzFfDY93PCchtF hsyWhOPDNRRCMx6U1WHzAt3Yn9gYbiKbDJZp7KmGaaiGnJaXr/VvbTstosSdNdRkGmyq SQFoWQyNfzQNYrnPGc4DtEP87kLei72YfvGAEdXNEXvJVLLKQjgjSRzU9KQwbeX4gwrP yJ9eI8VEDNJ3A67aIooTZ7pNG5JcRTB+1zBdFaEQ+nDh90tpbSmi+eSYIKLeUDiqwUfw h6bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=+AXpgMmuL3NSvfn8iBTUkD9z8GYz9GV/xJMhFU7McSc=; b=wnrG+ySDYbYgVInO+99LeZ8ueQoPSSGhv49uiiXo3SKtUM92gZny7ylaf3lDSUE7ya t7hW70VRjt4KUMLtEBVtZAVUVu5TA+v6J3LrmrV6Wz7iFtSxUnliHJoHaC6qP/7m66Vo 74yAGOAzyCa5ATjgLR0lIYxdZDYz5KMS2bG1zmpj9FTFePu64qVKH0nQZ2EHOEY1ox2/ yZ65EUaq6rC5byl9OSLdeKLdLk1Oe0PTyVSEyhCtxeeBQE/oFojtE9Xy1VC0+MTeJ31q pd3gKIXZyllQX0rzaGVG61BmqUn5GetG9pak7JREN/MBmZD3Tpow52sGg6R4f46NLaUr ntJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Hj80HcFk; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t3-20020a056402524300b00468ccfbba7asi15797484edd.387.2022.12.14.17.11.40; Wed, 14 Dec 2022 17:12:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Hj80HcFk; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229834AbiLOBBd (ORCPT + 99 others); Wed, 14 Dec 2022 20:01:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229787AbiLOBBa (ORCPT ); Wed, 14 Dec 2022 20:01:30 -0500 Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B96F746655 for ; Wed, 14 Dec 2022 17:01:26 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id l127so4105984oia.8 for ; Wed, 14 Dec 2022 17:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=+AXpgMmuL3NSvfn8iBTUkD9z8GYz9GV/xJMhFU7McSc=; b=Hj80HcFk1+wGgWdM0qYtfoEP118g7pnbDZ1iaONKLRyq7ALD/XEV7vVSxyeyG5C332 DuC73/7jKGMCEB1dULH+KLHOKSeumpkwpUW+GG68qvMmQss4v6sir0gMkHngJ4x1PdNs 8vdv6ESeeyQvXXjiXz48kEds4m3Lm1jtvmFWcha7pPVkxpn+OyzTG9/53OGVegS45kva 5BafxskuHY7iVDaqjM/QPv26NHNdJ8WRDt4flC21tJbgAsNeqEiTNTWmog0Muzakrg+B VTXrP+16m5YsUQA7uxS09XE7vABC6lHuib020amhH4dBXy3QWuaWt/Jwty6r6MYSoUQT 6e1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+AXpgMmuL3NSvfn8iBTUkD9z8GYz9GV/xJMhFU7McSc=; b=w/yBXvjXQOuL3J/YckVusYQ/xQfKZgJ8POobLnjPgjjRRYeKh3+eRs/snCPR5pJn0V FjjBQkcUQ9Nkd4DLt8J3huO6bH/S4t23q/jm9DUvx00RVnara5Y40FteWAUFljtLPIvT hQxFmMPrXzofh0kxWY0RCCVlmaoxrRAxeABxLttd7Nib8PRHtARrFNnejLHdUyK2gUS+ DJRBU6be1KDgXxnlaqjzafAXRx01SLZDtm5kvi72V/EdLNvGlGoiwhI6zX6ArAh1QsX+ YPHChIRo4JRed1B+mEMvWMzkDopkBMZxJiUHf2/vMcYvJgl/BWKB61SRwUYIaqj0Z86s TBuQ== X-Gm-Message-State: ANoB5pk0u09ICyLgEpbN3jjxulw37RaOAebpp1Za54sfsWSyqumPofjX 5MEoH0b1R3Q2lr+b0yXfMCCEog== X-Received: by 2002:a05:6808:2387:b0:35e:9bb3:b8fa with SMTP id bp7-20020a056808238700b0035e9bb3b8famr7121698oib.51.1671066085845; Wed, 14 Dec 2022 17:01:25 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id i8-20020a05620a404800b006feea093006sm11137891qko.124.2022.12.14.17.01.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Dec 2022 17:01:24 -0800 (PST) Date: Wed, 14 Dec 2022 17:01:13 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Michael Roth cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, dgilbert@redhat.com, jarkko@kernel.org, ashish.kalra@amd.com, harald@profian.com, Hugh Dickins Subject: Re: [PATCH RFC v7 21/64] x86/fault: fix handle_split_page_fault() to work with memfd backed pages In-Reply-To: <20221214194056.161492-22-michael.roth@amd.com> Message-ID: <7f2228c4-1586-2934-7b92-1a9d23b6046@google.com> References: <20221214194056.161492-1-michael.roth@amd.com> <20221214194056.161492-22-michael.roth@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, 14 Dec 2022, Michael Roth wrote: > From: Hugh Dickins > > When the address is backed by a memfd, the code to split the page does > nothing more than remove the PMD from the page tables. So immediately > install a PTE to ensure that any other pages in that 2MB region are > brought back as in 4K pages. > > Signed-off-by: Hugh Dickins > Cc: Hugh Dickins > Signed-off-by: Ashish Kalra > Signed-off-by: Michael Roth Hah, it's good to see this again, but it was "Suggested-by" me, not "Signed-off-by" me. And was a neat pragmatic one-liner workaround for the immediate problem we had, but came with caveats. The problem is that we have one wind blowing in the split direction, and another wind (khugepaged) blowing in the collapse direction, and who wins for how long depends on factors I've not fully got to grips with (and is liable to differ between kernel releases). Good and bad timing to see it. I was just yesterday reviewing a patch to the collapsing wind, which reminded me of an improvement yet to be made there, thinking I'd like to try it sometime; but recallng that someone somewhere relies on the splitting wind, and doesn't want the collapsing wind to blow any harder - now you remind me who! Bad timing in that I don't have any quick answer on the right thing to do instead, and can't give it the thought it needs at the moment - perhaps others can chime in more usefully. Hugh p.s. I don't know where "handle_split_page_fault" comes in, but "x86/fault" in the subject looks wrong, since this appears to be in generic code; and "memfd" seems inappropriate too, but perhaps you have a situation where only memfds can reach handle_split_page_fault(). > --- > mm/memory.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/mm/memory.c b/mm/memory.c > index e68da7e403c6..33c9020ba1f8 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -4999,6 +4999,11 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf) > static int handle_split_page_fault(struct vm_fault *vmf) > { > __split_huge_pmd(vmf->vma, vmf->pmd, vmf->address, false, NULL); > + /* > + * Install a PTE immediately to ensure that any other pages in > + * this 2MB region are brought back in as 4K pages. > + */ > + __pte_alloc(vmf->vma->vm_mm, vmf->pmd); > return 0; > } > > -- > 2.25.1