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 B8A13CE7AB9 for ; Fri, 6 Sep 2024 07:05:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E2E46B0082; Fri, 6 Sep 2024 03:05:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 46C316B0088; Fri, 6 Sep 2024 03:05:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 334346B0089; Fri, 6 Sep 2024 03:05:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 14B9D6B0082 for ; Fri, 6 Sep 2024 03:05:53 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 98CFF41063 for ; Fri, 6 Sep 2024 07:05:52 +0000 (UTC) X-FDA: 82533428544.17.7A861E4 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf05.hostedemail.com (Postfix) with ESMTP id 7C7EA100008 for ; Fri, 6 Sep 2024 07:05:50 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725606253; 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; bh=sB276zOl5ew0cGnW2ccm/eoZmsgmhMmrNXOjemMHCCE=; b=u2oYc678QRAO8fH72okY1MAYNWPRLv9R9FXcU1hrdgLl5+8DXgcnHrobsxCNykro9zurwT e98TEJ8/3FMVdIp4HEaReGFkize5vSap+S5R+t+zBZuPzzV14RNL9E63+gkFW+l1uJZ5tz q8UJk29vNUcd5TdctwJUnqR+Xre0Z2g= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725606253; a=rsa-sha256; cv=none; b=Yg0kW0RTG5NS4aPVM+MNaagPmcPDaNmmFU0ibcVkm7C1sX/MAEprdWDfxmc6PeTPvjtacD fMrRu5uXBBqRfH7QhRltrekoE6fx+wsFaysxfKAq1not7rY5Igjttcluu+vcjo7ynQtLQX ianYoi8sd3UAbpRx6/UHfvUpGEENOxc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5EB13FEC; Fri, 6 Sep 2024 00:06:16 -0700 (PDT) Received: from [10.162.41.22] (e116581.arm.com [10.162.41.22]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 021343F66E; Fri, 6 Sep 2024 00:05:41 -0700 (PDT) Message-ID: <7b7c5dc8-933b-405f-be27-907624f7f8ce@arm.com> Date: Fri, 6 Sep 2024 12:35:38 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] mm: Allocate THP on hugezeropage wp-fault To: Ryan Roberts , akpm@linux-foundation.org, david@redhat.com, willy@infradead.org, kirill.shutemov@linux.intel.com Cc: anshuman.khandual@arm.com, catalin.marinas@arm.com, cl@gentwo.org, vbabka@suse.cz, mhocko@suse.com, apopple@nvidia.com, dave.hansen@linux.intel.com, will@kernel.org, baohua@kernel.org, jack@suse.cz, mark.rutland@arm.com, hughd@google.com, aneesh.kumar@kernel.org, yang@os.amperecomputing.com, peterx@redhat.com, ioworker0@gmail.com, jglisse@google.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20240904100923.290042-1-dev.jain@arm.com> <20240904100923.290042-3-dev.jain@arm.com> <542b8267-39de-4593-82ef-a586bb372824@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: <542b8267-39de-4593-82ef-a586bb372824@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7C7EA100008 X-Stat-Signature: hcp5yjhtbzy7w19bqaigr9hx4iuz8zkq X-HE-Tag: 1725606350-817168 X-HE-Meta: U2FsdGVkX19RYzgwEfV8v70qtf4MRgDIIaSERxq4qZUdhWCoQjIk7Ae1jFDm8zfnYJ3179+u+1u8WueiRxWG1TA71D36GEPWW1x2XUWO9+c02QXxAZ7aXUKHWWH4TwJQ6iHFb+K5eMNGEZBNvFgbrdNjeudr/xbH6kuGllZDaHt8jCVqO52AqfJdfCa1oMQ/ZGlGgP04uRxcz4U2ML2G1zdUj9kDghDhgZ1/eOUvhsdwZo7ZrcR59Hr5kJFSwJEmETzCi3IUw7zQE7DV2rCrefA6o9jclkpZUFZyc14/kRvDPzCmusE/zidOhXbEvwPH3Sgu/wIeKsn+scFN/Jvp+kRlI7E7bizpcPzXX2Vi/kkzoDgioB1K6y03XtrDnDQj3xJJn2WI2WxINKoz5v36KLU3xtc1LJ61y2ZUSvOQfYQ+lC4jneRqbGapTO5BYNoBfUClSXFjTxF4S9c1IRaJ3U3cX47m1p8Qw3VlG8Lv9W1wFoK6nvg8LryCtwm6pZWMqozBi4pE+h3V53CD6jkRLvHWYHyoPnrHWJlhlpV8rGPh8ITy6yl737UCNGq02ds7uc/K/HQkAu3UJdj1MaZRy7DjXD14yV/+qvvHWD0AIGEkjU83LMDZCmWYh7M252iT9a8YQ1cwNQlfqK3LKXfsvKMESHIFPIz+3rfYJmu7e7cQR43LA9yI5UyBQFidnr8giXFjuv+Rwm4hkCP+1E6iyDzAVD8sjdjQc+ba2MVf5X5SSsREzo8s93BapH7oFWhVmEMos4X1hyZupPOw1bRVgleAGEcG5J2+eKQlnlmMZVgLQsB5w9wApi1XbRXsuseSEnlosb40ZsqV9ORVcg5wLNVaCwcrHDUl8BezrEDW6wuaMJMkGDZs6ti6pNJ2oMZKZccNAghNkfgam+3DDq1JSWxZn9MWqKmHTquIo4PHs0Lvxf7QbIoT5VRyTDbKQnes03F+NOyMWS29zDn3kZU Avx6bN4V zlzAAPc2BACAZkq8R2tnho42WHB2ROsHbjFBiCR8+72sWRe6akqM56nwXrIoRqxh3VumY2sB/gQBsk0eJDT0hMUhQFW6N6+Vrp181+Apqb57fdS/ttbpjPVp2GyhBB5GfycWlwsRPsX4DkpFxcZSearIxRhuGBXzoA7ZQIa4WGcrLwKCjm8KVVhQjsK9vBlb5L1EtDuUQJ3kaE8E= 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: List-Subscribe: List-Unsubscribe: On 9/5/24 18:44, Ryan Roberts wrote: > On 04/09/2024 11:09, Dev Jain wrote: >> Introduce do_huge_zero_wp_pmd() to handle wp-fault on a hugezeropage and >> replace it with a PMD-mapped THP. Change the helpers introduced in the >> previous patch to flush TLB entry corresponding to the hugezeropage, >> and preserve PMD uffd-wp marker. In case of failure, fallback to >> splitting the PMD. >> >> Signed-off-by: Dev Jain >> --- >> include/linux/huge_mm.h | 6 ++++ >> mm/huge_memory.c | 79 +++++++++++++++++++++++++++++++++++------ >> mm/memory.c | 5 +-- >> 3 files changed, 78 insertions(+), 12 deletions(-) >> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >> index e25d9ebfdf89..fdd2cf473a3c 100644 >> --- a/include/linux/huge_mm.h >> +++ b/include/linux/huge_mm.h >> @@ -9,6 +9,12 @@ >> #include >> >> vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf); >> +vm_fault_t thp_fault_alloc(gfp_t gfp, int order, struct vm_area_struct *vma, >> + unsigned long haddr, struct folio **foliop, >> + unsigned long addr); >> +void map_pmd_thp(struct folio *folio, struct vm_fault *vmf, >> + struct vm_area_struct *vma, unsigned long haddr, >> + pgtable_t pgtable); > I don't think you are using either of these outside of huge_memory.c, so not > sure you need to declare them here or make them non-static? As pointed out by Kirill, you are right, I forgot to drop these from my previous approach. > >> int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm, >> pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long addr, >> struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma); >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >> index 58125fbcc532..150163ad77d3 100644 >> --- a/mm/huge_memory.c >> +++ b/mm/huge_memory.c >> @@ -943,9 +943,9 @@ unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, >> } >> EXPORT_SYMBOL_GPL(thp_get_unmapped_area); >> >> -static vm_fault_t thp_fault_alloc(gfp_t gfp, int order, struct vm_area_struct *vma, >> - unsigned long haddr, struct folio **foliop, >> - unsigned long addr) >> +vm_fault_t thp_fault_alloc(gfp_t gfp, int order, struct vm_area_struct *vma, >> + unsigned long haddr, struct folio **foliop, >> + unsigned long addr) >> { >> struct folio *folio = vma_alloc_folio(gfp, order, vma, haddr, true); >> >> @@ -984,21 +984,29 @@ static void __thp_fault_success_stats(struct vm_area_struct *vma, int order) >> count_memcg_event_mm(vma->vm_mm, THP_FAULT_ALLOC); >> } >> >> -static void map_pmd_thp(struct folio *folio, struct vm_fault *vmf, >> - struct vm_area_struct *vma, unsigned long haddr, >> - pgtable_t pgtable) >> +void map_pmd_thp(struct folio *folio, struct vm_fault *vmf, >> + struct vm_area_struct *vma, unsigned long haddr, >> + pgtable_t pgtable) >> { >> - pmd_t entry; >> + pmd_t entry, old_pmd; >> + bool is_pmd_none = pmd_none(*vmf->pmd); >> >> entry = mk_huge_pmd(&folio->page, vma->vm_page_prot); >> entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); >> folio_add_new_anon_rmap(folio, vma, haddr, RMAP_EXCLUSIVE); >> folio_add_lru_vma(folio, vma); >> - pgtable_trans_huge_deposit(vma->vm_mm, vmf->pmd, pgtable); >> + if (!is_pmd_none) { >> + old_pmd = pmdp_huge_clear_flush(vma, haddr, vmf->pmd); >> + if (pmd_uffd_wp(old_pmd)) >> + entry = pmd_mkuffd_wp(entry); > I don't really get this; entry is writable, so I wouldn't expect to also be > setting uffd-wp here? That combination is not allowed and is checked for in > page_table_check_pte_flags(). > > It looks like you expect to get here in the uffd-wp-async case, which used to > cause the pmd to be split to ptes. I'm guessing (but don't know for sure) that > would cause the uffd-wp bit to be set in each of the new ptes, then during > fallback to handling the wp fault on the pte, uffd would handle it? I guess you are correct; I missed the WARN_ON() in page_table_check_pmd_flags(), but I did see, if I read the uffd code correctly, that mfill_atomic() will just return in case of pmd_trans_huge(*dst_pmd) while doing a uffd_copy to the destination location. So preserving pmd_uffd_wp is useless in case a THP is mapped, but I did not know that in fact it is supposed to be an invalid combination. So, I will drop it, unless someone has some other objection. > >> + } >> + if (pgtable) >> + pgtable_trans_huge_deposit(vma->vm_mm, vmf->pmd, pgtable); > Should this call be moved outside of here? It doesn't really feel like it > belongs. Could it be called before calling map_pmd_thp() for the site that has a > pgtable? Every other place I checked, they are doing this: make the entry -> deposit pgtable -> set_pmd_at(). I guess the general flow is to do the deposit based on the old pmd, before setting the new one. Which implies: I should at least move this check before I call pmdp_huge_clear_flush(). And, since vmf->pmd and creating the new entry has no relation, I am inclined to do what you are saying. > >> set_pmd_at(vma->vm_mm, haddr, vmf->pmd, entry); >> update_mmu_cache_pmd(vma, vmf->address, vmf->pmd); >> add_mm_counter(vma->vm_mm, MM_ANONPAGES, HPAGE_PMD_NR); >> - mm_inc_nr_ptes(vma->vm_mm); >> + if (is_pmd_none) >> + mm_inc_nr_ptes(vma->vm_mm); >> } >> >> static vm_fault_t __do_huge_pmd_anonymous_page(struct vm_fault *vmf) >> @@ -1576,6 +1584,50 @@ void huge_pmd_set_accessed(struct vm_fault *vmf) >> spin_unlock(vmf->ptl); >> } >> >> +static vm_fault_t do_huge_zero_wp_pmd_locked(struct vm_fault *vmf, >> + unsigned long haddr, >> + struct folio *folio) >> +{ >> + struct vm_area_struct *vma = vmf->vma; >> + vm_fault_t ret = 0; >> + >> + ret = check_stable_address_space(vma->vm_mm); >> + if (ret) >> + goto out; >> + map_pmd_thp(folio, vmf, vma, haddr, NULL); >> +out: >> + return ret; >> +} >> + >> +static vm_fault_t do_huge_zero_wp_pmd(struct vm_fault *vmf, unsigned long haddr) >> +{ >> + struct vm_area_struct *vma = vmf->vma; >> + gfp_t gfp = vma_thp_gfp_mask(vma); >> + struct mmu_notifier_range range; >> + struct folio *folio = NULL; >> + vm_fault_t ret = 0; >> + >> + ret = thp_fault_alloc(gfp, HPAGE_PMD_ORDER, vma, haddr, &folio, >> + vmf->address); > Just checking: the PTE table was already allocated during the read fault, right? > So we don't have to allocate it here. Correct, that happens in set_huge_zero_folio(). Thanks for checking. > >> + if (ret) >> + goto out; >> + >> + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma->vm_mm, haddr, >> + haddr + HPAGE_PMD_SIZE); >> + mmu_notifier_invalidate_range_start(&range); >> + vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd); >> + if (unlikely(!pmd_same(pmdp_get(vmf->pmd), vmf->orig_pmd))) >> + goto unlock; >> + ret = do_huge_zero_wp_pmd_locked(vmf, haddr, folio); >> + if (!ret) >> + __thp_fault_success_stats(vma, HPAGE_PMD_ORDER); >> +unlock: >> + spin_unlock(vmf->ptl); >> + mmu_notifier_invalidate_range_end(&range); > I'll confess I don't understand all the mmu notifier rules. I confess the same :) > But the doc at > Documentation/mm/mmu_notifier.rst implies that the notification must be done > while holding the PTL. Although that's not how wp_page_copy(). Are you confident > what you have done is correct? Everywhere else, invalidate_range_end() is getting called after dropping the lock, one reason is that it has a might_sleep(), and therefore we cannot call it while holding a spinlock. I still don't know what exactly these calls mean...but I think what I have done is correct. > > Thanks, > Ryan > >> +out: >> + return ret; >> +} >> + >> vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf) >> { >> const bool unshare = vmf->flags & FAULT_FLAG_UNSHARE; >> @@ -1588,8 +1640,15 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf) >> vmf->ptl = pmd_lockptr(vma->vm_mm, vmf->pmd); >> VM_BUG_ON_VMA(!vma->anon_vma, vma); >> >> - if (is_huge_zero_pmd(orig_pmd)) >> + if (is_huge_zero_pmd(orig_pmd)) { >> + vm_fault_t ret = do_huge_zero_wp_pmd(vmf, haddr); >> + >> + if (!(ret & VM_FAULT_FALLBACK)) >> + return ret; >> + >> + /* Fallback to splitting PMD if THP cannot be allocated */ >> goto fallback; >> + } >> >> spin_lock(vmf->ptl); >> >> diff --git a/mm/memory.c b/mm/memory.c >> index 3c01d68065be..c081a25f5173 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -5409,9 +5409,10 @@ static inline vm_fault_t wp_huge_pmd(struct vm_fault *vmf) >> if (vma_is_anonymous(vma)) { >> if (likely(!unshare) && >> userfaultfd_huge_pmd_wp(vma, vmf->orig_pmd)) { >> - if (userfaultfd_wp_async(vmf->vma)) >> + if (!userfaultfd_wp_async(vmf->vma)) >> + return handle_userfault(vmf, VM_UFFD_WP); >> + if (!is_huge_zero_pmd(vmf->orig_pmd)) >> goto split; >> - return handle_userfault(vmf, VM_UFFD_WP); >> } >> return do_huge_pmd_wp_page(vmf); >> }