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 1A492C433FE for ; Thu, 29 Sep 2022 18:29:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9206C8D0003; Thu, 29 Sep 2022 14:29:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A97A8D0001; Thu, 29 Sep 2022 14:29:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D51B8D0003; Thu, 29 Sep 2022 14:29:41 -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 578E88D0001 for ; Thu, 29 Sep 2022 14:29:41 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 23B33120ACA for ; Thu, 29 Sep 2022 18:29:41 +0000 (UTC) X-FDA: 79965961362.21.7AD6151 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf04.hostedemail.com (Postfix) with ESMTP id 8299F40016 for ; Thu, 29 Sep 2022 18:29:40 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id x1so1965692plv.5 for ; Thu, 29 Sep 2022 11:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=r7x8U2WWuZqtH2rrIIcS2XynHY/yseYye2zrqMM6Et8=; b=gDrN6VJe+mCeTqrI0ZJHo1vweqUHeLnG/QtkQ+DoIZUwHtCLrxLaLVwR+HfP0pk41R oQkzMBxK6quJZhURlfZMiFJRRilyfqlTU8W3FeDE5jpIgCpMTH1M7HGSP0CTu3vAYn5G 4d67xxs/L19iljmPtkYgInGVP6V9KxOlxi/70U13iGVrCE7WIXayTIVsHTxti2WBr478 Eb9hLQuC1tEIztpaLGBKIG89t+D1Hw4bDR+UQHZL8Z4zX7fPHV4wIkMwRUEVkiEkmr9H paogj3j45ErOKFiW3J3li+JkffObx3c5wCBMs995tNn43vcRmDI272qWCodVqbP24vec gWdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=r7x8U2WWuZqtH2rrIIcS2XynHY/yseYye2zrqMM6Et8=; b=G9OQrSlgsdVNnVwQox6XFT4h2DR4cMUde+d2fVKFiBuEnS1i/YCyIGqAVZ3q4GnEFN Vj/CtIslQgTLwrhvCEqdeJ1pVtw+i3/SHvfqH5gqiN+aTBxL4u5ddVJvSiuW9jhqS/1T E8Jf4HLLNHP9SOSkI3lfqPKOgRBVQiXI5fyNru2V6pcMZoSZkplidkK7iHQ2UEgdOAHw lx25BPurLPFvUaO6GjD97bGHt3TGi5g80dirp5YMPX9grsTXV1Nkn1EjMQJkdDMYsec5 qGosk7IJe8am9rYunAwwEmu5BlqreomeU5kP4QJjlarsYuc2ytEODcYIafKbdKNxIsOO lhAg== X-Gm-Message-State: ACrzQf22oI8vdRm4QgsFZ9n9n9QJaN4elExH+EZhVU/R9mucVFfDXX2O zvq64uh1RkAGGzrHD2mPYTA= X-Google-Smtp-Source: AMsMyM69Bm1HmjgbgetOCpH4aYTLjOTBB4jR0voRxC+PtRzFPtyZi2oqA4ER07OJGC3jLIcNy6908w== X-Received: by 2002:a17:902:d48d:b0:178:306d:f75c with SMTP id c13-20020a170902d48d00b00178306df75cmr4635850plg.73.1664476179293; Thu, 29 Sep 2022 11:29:39 -0700 (PDT) Received: from strix-laptop (2001-b011-20e0-1b9a-f5f9-665b-0715-9cc1.dynamic-ip6.hinet.net. [2001:b011:20e0:1b9a:f5f9:665b:715:9cc1]) by smtp.gmail.com with ESMTPSA id m9-20020a170902db0900b0016c09a0ef87sm178417plx.255.2022.09.29.11.29.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 11:29:38 -0700 (PDT) Date: Fri, 30 Sep 2022 02:29:32 +0800 From: Chih-En Lin To: David Hildenbrand 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 Subject: Re: [RFC PATCH v2 9/9] mm: Introduce Copy-On-Write PTE table Message-ID: References: <20220927162957.270460-1-shiyn.lin@gmail.com> <20220927162957.270460-10-shiyn.lin@gmail.com> <3D21021E-490F-4FE0-9C75-BB3A46A66A26@vmware.com> <39c5ef18-1138-c879-2c6d-c013c79fa335@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39c5ef18-1138-c879-2c6d-c013c79fa335@redhat.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664476180; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=r7x8U2WWuZqtH2rrIIcS2XynHY/yseYye2zrqMM6Et8=; b=Y1x5MiYCMVXcbnvGxYh9b5BPP5WBlsE0jZTRqplpPFLlQc/pGGjCMnJlxrMgU4EXDTu7QC mK7SGBh4pQevaSFXsAq6xgKoo6Bh+KyQ1twpmX0xWLQ13D8Hh6Ut+qMO/DuRI28EzK9dp+ kRhwLhk1fRZaM3WSmZkPaoxpbmSpLJA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gDrN6VJe; spf=pass (imf04.hostedemail.com: domain of shiyn.lin@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=shiyn.lin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664476180; a=rsa-sha256; cv=none; b=AF0oo5z4DNrLl6SAcF5X+g+QxwkltrQSEc/WVYizrQIWUbj/kqeV5OXhJlypcjiklcNW3z NuCvnqpIKR+iUSGuzGOvd6mF2RvSRbAJ95Pdl9WXYvz24YONI/x3C7Zdt41oKEZdKtc3lR Yl2IzXCbrKreFb7chsvlp2gzznW/NDM= Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gDrN6VJe; spf=pass (imf04.hostedemail.com: domain of shiyn.lin@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=shiyn.lin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Stat-Signature: p5o4tbwgkz75ubay9xkcsxdwo7fw7am5 X-Rspamd-Queue-Id: 8299F40016 X-Rspamd-Server: rspam08 X-HE-Tag: 1664476180-91047 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, Sep 29, 2022 at 07:24:31PM +0200, David Hildenbrand wrote: > > > 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? > My consideration is when we pinned the page and did the COW to make the page table be shared. It might not allow mapping the pinned page to R/O) into both processes. So, if the fork is working on the shared state, it needs to recover the table and copy to a new one since that pinned page will need to copy immediately. We can hold the shared state after occurring such a situation. So we still need some trick to let the fork() know which page table already has the pinned page (or such page won't let us share) before going to duplicate. Am I wrong here? After that, since we handled the accounting in fork(), we don't need ownership (pmd_t pointer) anymore. We have to find another way to mark the table to be exclusive. (Right now, COW_PTE_OWNER_EXCLUSIVE flag is stored at that space.) > > > > > 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 is what I want to say above. The case might happen in the middle of the shared page table progress. It might cost more overhead to recover it. Therefore, if GUP wants to pin the mapped page we can mark the PTE table first, so fork() won't waste time doing the work for sharing. > 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. Sounds good. :) > -- > Thanks, > > David / dhildenb > Thanks, Chih-En Lin