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 92C4EC2BA4C for ; Wed, 26 Jan 2022 20:36:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4CEB6B0072; Wed, 26 Jan 2022 15:36:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AFBB36B0075; Wed, 26 Jan 2022 15:36:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99DAD6B007B; Wed, 26 Jan 2022 15:36:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id 85F616B0072 for ; Wed, 26 Jan 2022 15:36:17 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 47ECE181CB2DD for ; Wed, 26 Jan 2022 20:36:17 +0000 (UTC) X-FDA: 79073595594.07.FC77A0C Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf11.hostedemail.com (Postfix) with ESMTP id D754B40011 for ; Wed, 26 Jan 2022 20:36:16 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id p7so763701edc.12 for ; Wed, 26 Jan 2022 12:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHSZGcqASjvkDHfsWnxtZXfgdyFpTFjH+EicTP6DUw0=; b=A1glERp8hCYBWE0s6Te6kySPMXGfZTwbtiiz/dCOcPbUse+bVmCxGmO4uUTeZd8knA H2yxCCBdKS3zQpXpvS/87lgCI+WV/PNj8cBYIwQwrkgBHtMOd5M148yu51TuuHBzZ/Vg VIFu5s+0RUbBhbQDZHU4DwQe9XC9QU6NnKugmw2mV+R+Fnl+9Q+668FpCFjnGilMYEAz kPl384LKwJmW/sVXQDzzJftBLxl30IEzGCYMsPCHQv02Cql+xoXrQ3KMtroJu79sqUGt 8kS96HN66s/g/Dl3IgrFaMw2GoKwflqumvPjALvV54g2jcpLLVPH1F+Jj7razSbPCqkQ 80Rg== 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=wHSZGcqASjvkDHfsWnxtZXfgdyFpTFjH+EicTP6DUw0=; b=dQZmRJztzqM+uDa0MbNYGlJTeEktJU6rkxDLR8g1SpY7oMcOqwAIBbeOFezkAUwfpy 4uKl2j05a6cZZPYvksPp5/lda28QdLpvdpH3hsUzm2x8OqLPyx8wefLBymfOf95GraQO uc2nvB0hACf65PK1V0lTo87v0lsjjGOALtnETgV89nO9o/ctdMBR5OFktXcCGiLxvUW9 dHCFojYWazGHp2czrdnSRUYDLJZ0JNy1EdVwBBe9a7Jq87OvWRoJq/fH3I1fF9+d34jJ TcbtMD8IY8v+UmMbt1g1g1x/x1hqMUr8DeE6/w4LMRPcLHjO5XvCV2b9DMvPwpiW4shr jVtA== X-Gm-Message-State: AOAM5322uAe+Gys2nJzZI75V6pVY+0yaA9jd/s6gfLc37QoALIOeSrYH SrlYaVz3KjOtTRNffzeteHOiMHu24r4TvzxrJoI= X-Google-Smtp-Source: ABdhPJymQFRnl1th966BHdwXeL7L1vz9+yol/C1udrCqwHSfpfpXGUAZ6980aKl2ej25WDZZ5uBbh89MkQ1nnNVaJnw= X-Received: by 2002:aa7:df16:: with SMTP id c22mr658273edy.177.1643229375413; Wed, 26 Jan 2022 12:36:15 -0800 (PST) MIME-Version: 1.0 References: <20220126095557.32392-1-david@redhat.com> <20220126095557.32392-6-david@redhat.com> In-Reply-To: <20220126095557.32392-6-david@redhat.com> From: Yang Shi Date: Wed, 26 Jan 2022 12:36:03 -0800 Message-ID: Subject: Re: [PATCH RFC v2 5/9] mm/huge_memory: streamline COW logic in do_huge_pmd_wp_page() To: David Hildenbrand Cc: Linux Kernel Mailing List , Andrew Morton , Hugh Dickins , Linus Torvalds , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , "Kirill A . Shutemov" , Matthew Wilcox , Vlastimil Babka , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Linux MM Content-Type: text/plain; charset="UTF-8" X-Rspam-User: nil X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D754B40011 X-Stat-Signature: qpssepncj3ujnewe7c8mbsrog37ewpxx Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=A1glERp8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-HE-Tag: 1643229376-280161 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, Jan 26, 2022 at 2:00 AM David Hildenbrand wrote: > > We currently have a different COW logic for anon THP than we have for > ordinary anon pages in do_wp_page(): the effect is that the issue reported > in CVE-2020-29374 is currently still possible for anon THP: an unintended > information leak from the parent to the child. > > Let's apply the same logic (page_count() == 1), with similar > optimizations to remove additional references first as we really want to > avoid PTE-mapping the THP and copying individual pages best we can. > > If we end up with a page that has page_count() != 1, we'll have to PTE-map > the THP and fallback to do_wp_page(), which will always copy the page. > > Note that KSM does not apply to THP. > > I. Interaction with the swapcache and writeback > > While a THP is in the swapcache, the swapcache holds one reference on each > subpage of the THP. So with PageSwapCache() set, we expect as many > additional references as we have subpages. If we manage to remove the > THP from the swapcache, all these references will be gone. > > Usually, a THP is not split when entered into the swapcache and stays a > compound page. However, try_to_unmap() will PTE-map the THP and use PTE > swap entries. There are no PMD swap entries for that purpose, consequently, > we always only swapin subpages into PTEs. > > Removing a page from the swapcache can fail either when there are remaining > swap entries (in which case COW is the right thing to do) or if the page is > currently under writeback. > > Having a locked, R/O PMD-mapped THP that is in the swapcache seems to be > possible only in corner cases, for example, if try_to_unmap() failed > after adding the page to the swapcache. However, it's comparatively easy to > handle. > > As we have to fully unmap a THP before starting writeback, and swapin is > always done on the PTE level, we shouldn't find a R/O PMD-mapped THP in the > swapcache that is under writeback. This should at least leave writeback > out of the picture. > > II. Interaction with GUP references > > Having a R/O PMD-mapped THP with GUP references (i.e., R/O references) > will result in PTE-mapping the THP on a write fault. Similar to ordinary > anon pages, do_wp_page() will have to copy sub-pages and result in a > disconnect between the GUP references and the pages actually mapped into > the page tables. To improve the situation in the future, we'll need > additional handling to mark anonymous pages as definitely exclusive to a > single process, only allow GUP pins on exclusive anon pages, and > disallow sharing of exclusive anon pages with GUP pins e.g., during > fork(). > > III. Interaction with references from LRU pagevecs > > Similar to ordinary anon pages, we can have LRU pagevecs referencing our > THP. Reliably removing such references requires draining LRU pagevecs on > all CPUs -- lru_add_drain_all() -- a possibly expensive operation that can > sleep. For now, similar do do_wp_page(), let's conditionally drain the > local LRU pagevecs only if we detect !PageLRU(). > > IV. Interaction with speculative/temporary references > > Similar to ordinary anon pages, other speculative/temporary references on > the THP, for example, from the pagecache or page migration code, will > disallow exclusive reuse of the page. We'll have to PTE-map the THP. > > Signed-off-by: David Hildenbrand > --- > mm/huge_memory.c | 19 +++++++++++++++---- > 1 file changed, 15 insertions(+), 4 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 406a3c28c026..b6ba88a98266 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -1286,6 +1286,7 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf) > struct page *page; > unsigned long haddr = vmf->address & HPAGE_PMD_MASK; > pmd_t orig_pmd = vmf->orig_pmd; > + int swapcache_refs = 0; > > vmf->ptl = pmd_lockptr(vma->vm_mm, vmf->pmd); > VM_BUG_ON_VMA(!vma->anon_vma, vma); > @@ -1303,7 +1304,6 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf) > page = pmd_page(orig_pmd); > VM_BUG_ON_PAGE(!PageHead(page), page); > > - /* Lock page for reuse_swap_page() */ > if (!trylock_page(page)) { > get_page(page); > spin_unlock(vmf->ptl); > @@ -1319,10 +1319,20 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf) > } > > /* > - * We can only reuse the page if nobody else maps the huge page or it's > - * part. > + * See do_wp_page(): we can only map the page writable if there are > + * no additional references. > */ > - if (reuse_swap_page(page)) { > + if (PageSwapCache(page)) > + swapcache_refs = thp_nr_pages(page); > + if (page_count(page) > 1 + swapcache_refs + !PageLRU(page)) > + goto unlock_fallback; > + if (!PageLRU(page)) > + lru_add_drain(); IMHO, draining lru doesn't help out too much for THP since THP will be drained to LRU immediately once it is added into pagevec. > + if (page_count(page) > 1 + swapcache_refs) > + goto unlock_fallback; > + if (swapcache_refs) > + try_to_free_swap(page); > + if (page_count(page) == 1) { > pmd_t entry; > entry = pmd_mkyoung(orig_pmd); > entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); > @@ -1333,6 +1343,7 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf) > return VM_FAULT_WRITE; > } > > +unlock_fallback: > unlock_page(page); > spin_unlock(vmf->ptl); > fallback: > -- > 2.34.1 >