From patchwork Tue Feb 8 05:46:32 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Muchun Song X-Patchwork-Id: 12738206 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 A16C9C433EF for ; Tue, 8 Feb 2022 05:47:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A4FD6B0075; Tue, 8 Feb 2022 00:47:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 153F46B0078; Tue, 8 Feb 2022 00:47:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 045946B007B; Tue, 8 Feb 2022 00:47:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0109.hostedemail.com [216.40.44.109]) by kanga.kvack.org (Postfix) with ESMTP id EB9AF6B0075 for ; Tue, 8 Feb 2022 00:47:01 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A911B824C421 for ; Tue, 8 Feb 2022 05:47:01 +0000 (UTC) X-FDA: 79118529042.23.7FFD1D1 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf18.hostedemail.com (Postfix) with ESMTP id 49C411C0004 for ; Tue, 8 Feb 2022 05:47:01 +0000 (UTC) Received: by mail-pl1-f172.google.com with SMTP id 10so5058937plj.1 for ; Mon, 07 Feb 2022 21:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=n5vkvz8TS8A/TWoh79lH9r9rs5OiOfx+UY7K0dS1wLk=; b=xwZoeurRxp/Fg3bZboK4CN/h1HC/Vg2P1EBa4IptVjAPnMpbRK/gio8e46NPXbSFaC 7fG0yYZX49kvJAtJ0Xe950EL3Vp5mjFK7BNO/w/tRA56PqaFarWT8v2+ygtfpPcdWzCT nY72MZd8q+CnrSKehtl2HKAhjf8HtybkzD5pQJIBsz5UlxbuQs7tqGX7usdbQ8Tsn4fl 7wFKlJe79Mz5TYLqmSpHZzQdae3GXihCcJ55cRmOdmR/DLkDAjpioTH0xKQEz9IlfzB1 GK9SsuSPHgMK/ahmN/M80aN8lch8JBxQrPJJY9wcYjmb1wHwae6WoN4279nhb0tzFeUc EmPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=n5vkvz8TS8A/TWoh79lH9r9rs5OiOfx+UY7K0dS1wLk=; b=JKHjezBbJcoyqdw/zqPoTeBqP3QldCELRb9zw/blnJCRTmaUxWW2TkQJGbJzfMOvSG n8ZkQoKguDZljEIs8A8clojT6Q8qDCQ5W9HoSvk0cMuCxopxOvYqWOZeshs6WBcCsVGf 583rPaj/WI3mdESYNS1T8C0qqE5vGj1cmurIKW0kUK9IVNRA33QlUdQO5fBtBGxrnBxY objF1TK1Snj8C45AgLUFlrU0Z+BmsMex7/P92Y0Qgj5gEk3B9nfkApWYxYbukkUU1xyv Syarq7gKPDts+4p1twLM63X53ZPxyxtyhjvOGQU8buCRqlZjXKo9L+srjNFDFIMz1uTr cMoQ== X-Gm-Message-State: AOAM531e5nY3lV4nXf63OR6oZ/KKFxNBAJhGgKwFa/LcmAvf/5c5CHMi reRNTb54/VcOy0cFKjd9D4Sgug== X-Google-Smtp-Source: ABdhPJxqPkFZwo6hekZ7v7KbQ6pLZIIZTjzsBs5X3gMiMmQSytNbA1jYRKeJ5f2FlbHZ9x6l3r+NOA== X-Received: by 2002:a17:90b:3ec8:: with SMTP id rm8mr2633625pjb.207.1644299219989; Mon, 07 Feb 2022 21:46:59 -0800 (PST) Received: from FVFYT0MHHV2J.tiktokcdn.com ([139.177.225.225]) by smtp.gmail.com with ESMTPSA id 20sm1160680pjf.15.2022.02.07.21.46.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Feb 2022 21:46:59 -0800 (PST) From: Muchun Song To: will@kernel.org, akpm@linux-foundation.org, david@redhat.com, bodeddub@amazon.com, osalvador@suse.de, mike.kravetz@oracle.com, rientjes@google.com, mark.rutland@arm.com, catalin.marinas@arm.com, james.morse@arm.com Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, duanxiongchun@bytedance.com, fam.zheng@bytedance.com, Muchun Song Subject: [PATCH v2 2/2] arm64: mm: hugetlb: add support for free vmemmap pages of HugeTLB Date: Tue, 8 Feb 2022 13:46:32 +0800 Message-Id: <20220208054632.66534-2-songmuchun@bytedance.com> X-Mailer: git-send-email 2.32.0 (Apple Git-132) In-Reply-To: <20220208054632.66534-1-songmuchun@bytedance.com> References: <20220208054632.66534-1-songmuchun@bytedance.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: 49C411C0004 X-Stat-Signature: p8hghwosuowstwq1d9wicstd86sqccbb X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=xwZoeurR; spf=pass (imf18.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Rspamd-Server: rspam05 X-HE-Tag: 1644299221-518424 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: The feature of minimizing overhead of struct page associated with each HugeTLB page aims to free its vmemmap pages (used as struct page) to save memory, where is ~14GB/16GB per 1TB HugeTLB pages (2MB/1GB type). In short, when a HugeTLB page is allocated or freed, the vmemmap array representing the range associated with the page will need to be remapped. When a page is allocated, vmemmap pages are freed after remapping. When a page is freed, previously discarded vmemmap pages must be allocated before remapping. More implementations and details can be found here [1]. The preparation of freeing vmemmap pages associated with each HugeTLB page is ready, so we can support this feature for arm64 now. The flush_dcache_page() need to be adapted to operate on the head page's flags since the tail vmemmap pages are mapped with read-only after the feature is enabled (clear operation is not permitted). There was some discussions about this in the thread [2], but there was no conclusion in the end. And I copied the concern proposed by Anshuman to here. 1st concern: ''' But what happens when a hot remove section's vmemmap area (which is being teared down) is nearby another vmemmap area which is either created or being destroyed for HugeTLB alloc/free purpose. As you mentioned HugeTLB pages inside the hot remove section might be safe. But what about other HugeTLB areas whose vmemmap area shares page table entries with vmemmap entries for a section being hot removed ? Massive HugeTLB alloc /use/free test cycle using memory just adjacent to a memory hotplug area, which is always added and removed periodically, should be able to expose this problem. ''' Answer: At the time memory is removed, all HugeTLB pages either have been migrated away or dissolved. So there is no race between memory hot remove and free_huge_page_vmemmap(). Therefore, HugeTLB pages inside the hot remove section is safe. Let's talk your question "what about other HugeTLB areas whose vmemmap area shares page table entries with vmemmap entries for a section being hot removed ?", the question is not established. The minimal granularity size of hotplug memory 128MB (on arm64, 4k base page), any HugeTLB smaller than 128MB is within a section, then, there is no share PTE page tables between HugeTLB in this section and ones in other sections and a HugeTLB page could not cross two sections. In this case, the section cannot be freed. Any HugeTLB bigger than 128MB (section size) whose vmemmap pages is an integer multiple of 2MB (PMD-mapped). As long as: 1) HugeTLBs are naturally aligned, power-of-two sizes 2) The HugeTLB size >= the section size 3) The HugeTLB size >= the vmemmap leaf mapping size Then a HugeTLB will not share any leaf page table entries with *anything else*, but will share intermediate entries. In this case, at the time memory is removed, all HugeTLB pages either have been migrated away or dissolved. So there is also no race between memory hot remove and free_huge_page_vmemmap(). 2nd concern: ''' differently, not sure if ptdump would require any synchronization. Dumping an wrong value is probably okay but crashing because a page table entry is being freed after ptdump acquired the pointer is bad. On arm64, ptdump() is protected against hotremove via [get|put]_online_mems(). ''' Answer: The ptdump should be fine since vmemmap_remap_free() only exchanges PTEs or split the PMD entry (which means allocating a PTE page table). Both operations do not free any page tables (PTE), so ptdump cannot run into a UAF on any page tables. The wrost case is just dumping an wrong value. [1] https://lore.kernel.org/all/20210510030027.56044-1-songmuchun@bytedance.com/ [2] https://lore.kernel.org/all/20210518091826.36937-1-songmuchun@bytedance.com/ Signed-off-by: Muchun Song --- Changes in v2: - Update commit message (Mark Rutland). - Fix flush_dcache_page(). arch/arm64/mm/flush.c | 14 ++++++++++++++ fs/Kconfig | 2 +- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c index a06c6ac770d4..705484a9b9df 100644 --- a/arch/arm64/mm/flush.c +++ b/arch/arm64/mm/flush.c @@ -75,6 +75,20 @@ EXPORT_SYMBOL_GPL(__sync_icache_dcache); */ void flush_dcache_page(struct page *page) { +#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP + /* + * Only the head page's flags of HugeTLB can be cleared since the tail + * vmemmap pages associated with each HugeTLB page are mapped with + * read-only when CONFIG_HUGETLB_PAGE_FREE_VMEMMAP is enabled (more + * details can refer to vmemmap_remap_pte()). Although + * __sync_icache_dcache() only set PG_dcache_clean flag on the head + * page struct, some tail page structs still can see the flag since + * the head vmemmap page frame is reused (more details can refer to + * the comments above page_fixed_fake_head()). + */ + if (PageHuge(page)) + page = compound_head(page); +#endif if (test_bit(PG_dcache_clean, &page->flags)) clear_bit(PG_dcache_clean, &page->flags); } diff --git a/fs/Kconfig b/fs/Kconfig index 7a2b11c0b803..04cfd5bf5ec9 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -247,7 +247,7 @@ config HUGETLB_PAGE config HUGETLB_PAGE_FREE_VMEMMAP def_bool HUGETLB_PAGE - depends on X86_64 + depends on X86_64 || ARM64 depends on SPARSEMEM_VMEMMAP config HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON