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 B03AAC433FE for ; Thu, 29 Sep 2022 17:24:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E133F8D0001; Thu, 29 Sep 2022 13:24:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC2BE6B0072; Thu, 29 Sep 2022 13:24:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C62B98D0001; Thu, 29 Sep 2022 13:24:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B36EF6B0071 for ; Thu, 29 Sep 2022 13:24:40 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7122E40496 for ; Thu, 29 Sep 2022 17:24:40 +0000 (UTC) X-FDA: 79965797520.16.E4E0BA3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id C5B0F1C0007 for ; Thu, 29 Sep 2022 17:24:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664472279; h=from:from: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=RMdm/8lzO3SbFCWw6w3QJ0nOlwN2WhTe2Z9N6/LMI7Y=; b=AgV08qRgwpALraKsKKx/YRU22U5VkVwgbyry6rzMNyHi7Z4dycsx8FjTfZiq+sKaVPmkS8 gd+dBv2yJxuaH753amkRkdu0UohZWo4QUUrva5kP+epsagyIckOfQ6/JD+rY8fFlEH5yps Tk6NYh0LYYbdGXtoGkV/a/79KFYsGZU= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-296-d2S7J0eMONWK767WA0iSig-1; Thu, 29 Sep 2022 13:24:35 -0400 X-MC-Unique: d2S7J0eMONWK767WA0iSig-1 Received: by mail-wr1-f72.google.com with SMTP id d18-20020adfa352000000b0022cbe33d2a5so779461wrb.11 for ; Thu, 29 Sep 2022 10:24:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=RMdm/8lzO3SbFCWw6w3QJ0nOlwN2WhTe2Z9N6/LMI7Y=; b=ZniKY3233/7cSK+o+tX204qwV0x3oEKybbjPWmrXIFQPOL1K6FU66bnGO5S7jGhtE1 OykBi6vWG8tyX3m6LhB+wRTn+uVwEOdt5HQIUaoRK9RXYKOfGMxkLS8jKWKmoR4TzWSu ddB6YlouodmU/ECs8wZUd6Mw78N68tfxgbFenwyr8SmdhvfdgloBQ5GPmC4eou9X1SHP eIKEq5uL8FSTOyeL/3KNtJSCxofFjWb6saCGJWs0zfJmTFLyozbiSZF6ZSU/wuN+zkY/ qBLU2trXsEQnw549oUZAIO8jn3ZIzZzWRSB0d4o2jJs57yBc2l1X9HgWXWA5noi1wwQZ IArw== X-Gm-Message-State: ACrzQf1B/y9DpGF4bAe/uiALC7LqdcBf5bYIJHn4P05YCei8O9uQV9qa 6oOAMkpzWm2JaC24h4cPpra30r6IHmp2yZmcdZ24Pcnab3mqcOSqL6N4lDA3+uwnpSyH3LQRAre EcC94VAtLFGQ= X-Received: by 2002:a5d:5b19:0:b0:22b:237c:3de8 with SMTP id bx25-20020a5d5b19000000b0022b237c3de8mr3155267wrb.285.1664472274095; Thu, 29 Sep 2022 10:24:34 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7jg3zCwylEVADfXVvACXXTeWwKVjgvqqVLjnWuAf0dqqxpK1iV3Hyk/9m1gxNGAUKxdoCEEw== X-Received: by 2002:a5d:5b19:0:b0:22b:237c:3de8 with SMTP id bx25-20020a5d5b19000000b0022b237c3de8mr3155232wrb.285.1664472273748; Thu, 29 Sep 2022 10:24:33 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:ce00:b5d:2b28:1eb5:9245? (p200300cbc705ce000b5d2b281eb59245.dip0.t-ipconnect.de. [2003:cb:c705:ce00:b5d:2b28:1eb5:9245]) by smtp.gmail.com with ESMTPSA id y15-20020adff14f000000b00224f7c1328dsm7058186wro.67.2022.09.29.10.24.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Sep 2022 10:24:33 -0700 (PDT) Message-ID: <39c5ef18-1138-c879-2c6d-c013c79fa335@redhat.com> Date: Thu, 29 Sep 2022 19:24:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 To: Chih-En Lin Cc: Nadav Amit , Andrew Morton , Qi Zheng , Matthew Wilcox , Christophe Leroy , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Luis Chamberlain , Kees Cook , Iurii Zaikin , Vlastimil Babka , William Kucharski , "Kirill A . Shutemov" , Peter Xu , Suren Baghdasaryan , Arnd Bergmann , Tong Tiangen , Pasha Tatashin , Li kunyu , Anshuman Khandual , Minchan Kim , Yang Shi , Song Liu , Miaohe Lin , Thomas Gleixner , Sebastian Andrzej Siewior , Andy Lutomirski , Fenghua Yu , Dinglan Peng , Pedro Fonseca , Jim Huang , Huichun Feng References: <20220927162957.270460-1-shiyn.lin@gmail.com> <20220927162957.270460-10-shiyn.lin@gmail.com> <3D21021E-490F-4FE0-9C75-BB3A46A66A26@vmware.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC PATCH v2 9/9] mm: Introduce Copy-On-Write PTE table In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AgV08qRg; spf=pass (imf21.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664472280; a=rsa-sha256; cv=none; b=fKacykzXxjo3Yhi903gLT3jBsSKh0pczvTouGtlRXg9s51d7Wzc4tLJ9cSl3SJFijz1DM5 P8E7fDNPVB1cdhxxz/gu/7acrcj1wYfM9+Hnx5SFad9PeNCM2erVkStKF8Y5yod0TX7447 WydjBc625Ltv9J23x0QWaIxDLvKwGtI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664472280; 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:dkim-signature; bh=RMdm/8lzO3SbFCWw6w3QJ0nOlwN2WhTe2Z9N6/LMI7Y=; b=UUaf8nalX77akgI1WI+JSqhdAIPl99ccnsmUuK4C2lWxjjvfPvr7gokq68PIXGrlDeLC0A il++Lqvj6dOTaTBLz6yqpX77CP3GJm+Q9kpbwVG4TuXoGa1e0nJBKlhqsKtbYmgkrlxUdY ZVJiR9FUgGR87ovMsUCt300KAHnNy5Y= X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AgV08qRg; spf=pass (imf21.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam10 X-Stat-Signature: 7hze9tgh9akjdaoaaftaqejsqpc77nzz X-Rspamd-Queue-Id: C5B0F1C0007 X-HE-Tag: 1664472279-969339 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: >> IMHO, a relaxed form that focuses on only the memory consumption reduction >> could *possibly* be accepted upstream if it's not too invasive or complex. >> During fork(), we'd do exactly what we used to do to PTEs (increment >> mapcount, refcount, trying to clear PageAnonExclusive, map the page R/O, >> duplicate swap entries; all while holding the page table lock), however, >> sharing the prepared page table with the child process using COW after we >> prepared it. >> >> Any (most once we want to *optimize* rmap handling) modification attempts >> require breaking COW -- copying the page table for the faulting process. But >> at that point, the PTEs are already write-protected and properly accounted >> (refcount/mapcount/PageAnonExclusive). >> >> Doing it that way might not require any questionable GUP hacks and swapping, >> MMU notifiers etc. "might just work as expected" because the accounting >> remains unchanged" -- we simply de-duplicate the page table itself we'd have >> after fork and any modification attempts simply replace the mapped copy. > > Agree. > However for GUP hacks, if we want to do the COW to page table, we still > need the hacks in this patch (using the COW_PTE_OWN_EXCLUSIVE flag to > check whether the PTE table is available or not before we do the COW to > the table). Otherwise, it will be more complicated since it might need > to handle situations like while preparing the COW work, it just figuring > out that it needs to duplicate the whole table and roll back (recover > the state and copy it to new table). Hopefully, I'm not wrong here. The nice thing is that GUP itself *usually* doesn't modify page tables. One corner case is follow_pfn_pte(). All other modifications should happen in the actual fault handler that has to deal with such kind of unsharing either way when modifying the PTE. If the pages are already in a COW-ed pagetable in the desired "shared" state (e.g., PageAnonExclusive cleared on an anonymous page), R/O pinning of such pages will just work as expected and we shouldn't be surprised by another set of GUP+COW CVEs. We'd really only deduplicate the page table and not play other tricks with the actual page table content that differ from the existing way of handling fork(). I don't immediately see why we need COW_PTE_OWN_EXCLUSIVE in GUP code when not modifying the page table. I think we only need "we have to unshare this page table now" in follow_pfn_pte() and inside the fault handling when GUP triggers a fault. I hope my assumption is correct, or am I missing something? > >> But devil is in the detail (page table lock, TLB flushing). > > Sure, it might be an overhead in the page fault and needs to be handled > carefully. ;) > >> "will make fork() even have more overhead" is not a good excuse for such >> complexity/hacks -- sure, it will make your benchmark results look better in >> comparison ;) > > ;);) > I think that, even if we do the accounting with the COW page table, it > still has a little bit improve. :) My gut feeling is that this is true. While we have to do a pass over the parent page table during fork and wrprotect all PTEs etc., we don't have to duplicate the page table content and allocate/free memory for that. One interesting case is when we cannot share an anon page with the child process because it maybe pinned -- and we have to copy it via copy_present_page(). In that case, the page table between the parent and the child would differ and we'd not be able to share the page table. That case could be caught in copy_pte_range(): in case we'd have to allocate a page via page_copy_prealloc(), we'd have to fall back to the ordinary "separate page table for the child" way of doing things. But that looks doable to me. -- Thanks, David / dhildenb