Received: by 2002:a05:7412:d1aa:b0:fc:a2b0:25d7 with SMTP id ba42csp881558rdb; Tue, 30 Jan 2024 01:04:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IEOPCtUpaMq0e8lt2f7l4pZI/+0yg85TVo5oFp/f/Pe7wDxhrGDUXXKI24eZtEqLqpRngow X-Received: by 2002:a05:6808:120b:b0:3bd:a866:124a with SMTP id a11-20020a056808120b00b003bda866124amr8122672oil.9.1706605442171; Tue, 30 Jan 2024 01:04:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706605442; cv=pass; d=google.com; s=arc-20160816; b=CBzkH+1dcM0M5+iBHvmaXi7nia41hfrSbBrU8A8O6i3HWfLX9Wi3aKIYPGDdRmA1gE dUdtV2x2xgOGLnSuT809sw9vE/nri39l+GAuXi4tTzbvlU+vc/9rOhdAO9+iuuTunnAO 2e4GmoTKlt18AUdmscIEKY807VB5o02CwFUa2IwalwIKo4UBbCoprpjHimq2mWR8sYgY kNc2BgUyq/mP++d+kd8DNalyXRyWoGufwpjeBhMEiqlAtsuVMRLJgiic8QYz0yjfi0NF 0MpoYyk+HLbqgk7+tv3GiaQgzhKj8NyQyNpTNt/s45x076phsBn1QeojZh89BiH7XyGX 3QHg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=jSEMVaK+rrlJNJ0zTwRLxVUfpM5jOWWKTKXrnzE7CEs=; fh=VVjuivqjwQTGD3KqdtfMHM2u5ZCac4G8eN8eVGHfbQw=; b=wOBp9ABBJMHS7Swi3RpVb+UqAXxVFGrf0YaJErQBZw7aLiQ80qriUfgIFzJJgI4TM0 BIWfVIVW+56OQabZgF8bFWv7AXYbqwceyLaiJG0dDt3etnuBNYscFufpePjUHOt6dEw4 TvHMh7LfHzwPBKeRa3Xfpx7WJpmLi0hU3MBIKOa3zbqA3uGVxB1slwKUHVoooBjj/K1t ZlhTEEPcFOjdC4G/MLfUvA1irze5lZLoivK1fBX7l34rq3YRok1lioRYR/uxTvOH+r86 pXUyZ+f25uTPnUNruYJaHwkZd4OuYlSpu5qcQdS9uE4cVI4C2KUu1LRlSRA/TsXr/NBR Y29w== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-44139-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44139-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id bs70-20020a632849000000b005cfbd190e57si6923479pgb.297.2024.01.30.01.04.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 01:04:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-44139-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-44139-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44139-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 21467B2950B for ; Tue, 30 Jan 2024 08:32:17 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0FBCF52F62; Tue, 30 Jan 2024 08:32:07 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4C10B76C79; Tue, 30 Jan 2024 08:32:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706603526; cv=none; b=jYODu2ud3XG3P2lia+f+Tzs+NgtB5YQPoEI9ujbCJCFr70v7WPfo7LCAkmrlF9i9Vt5bWksHMBMDD8n63v3nSudODmgM1qxljYcNELq36UXUVXnBGmLi0UFhzwbfp7vzy00kcOAwrpGbrHh4RaYudsclm39EbyVI3YFBYDh74oE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706603526; c=relaxed/simple; bh=giGHyUoP2JYDUN62HXLPUpAiCyVqPjkFQ+lvW+bcLEU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LrymoY92FfZn84H+Y6KjVDRD/f2JNCpERUNJXGzvJGSLCZnO8uMVTpeUqcvD1cX9tsYGxF5V+Ry3AFLf2Zp+PNLBsaVqirVzjBhUTwKxDXQ+0rtKw5sqX26kkBTceooY1vxY8U15igco8C+FTdXm+fsplood82nWFTu4diyU/9w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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 04441DA7; Tue, 30 Jan 2024 00:32:47 -0800 (PST) Received: from [10.57.79.54] (unknown [10.57.79.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4DEEE3F738; Tue, 30 Jan 2024 00:32:00 -0800 (PST) Message-ID: <40cfb242-ceb0-44c6-afe7-c1744825dc62@arm.com> Date: Tue, 30 Jan 2024 08:31:58 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 3/9] mm/memory: further separate anon and pagecache folio handling in zap_present_pte() Content-Language: en-GB To: David Hildenbrand , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Andrew Morton , Matthew Wilcox , Catalin Marinas , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Michael Ellerman , Christophe Leroy , "Naveen N. Rao" , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Arnd Bergmann , linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org References: <20240129143221.263763-1-david@redhat.com> <20240129143221.263763-4-david@redhat.com> From: Ryan Roberts In-Reply-To: <20240129143221.263763-4-david@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29/01/2024 14:32, David Hildenbrand wrote: > We don't need up-to-date accessed-dirty information for anon folios and can > simply work with the ptent we already have. Also, we know the RSS counter > we want to update. > > We can safely move arch_check_zapped_pte() + tlb_remove_tlb_entry() + > zap_install_uffd_wp_if_needed() after updating the folio and RSS. > > While at it, only call zap_install_uffd_wp_if_needed() if there is even > any chance that pte_install_uffd_wp_if_needed() would do *something*. > That is, just don't bother if uffd-wp does not apply. > > Signed-off-by: David Hildenbrand > --- > mm/memory.c | 16 +++++++++++----- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index 69502cdc0a7d..20bc13ab8db2 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -1552,12 +1552,9 @@ static inline void zap_present_pte(struct mmu_gather *tlb, > folio = page_folio(page); > if (unlikely(!should_zap_folio(details, folio))) > return; > - ptent = ptep_get_and_clear_full(mm, addr, pte, tlb->fullmm); > - arch_check_zapped_pte(vma, ptent); > - tlb_remove_tlb_entry(tlb, pte, addr); > - zap_install_uffd_wp_if_needed(vma, addr, pte, details, ptent); > > if (!folio_test_anon(folio)) { > + ptent = ptep_get_and_clear_full(mm, addr, pte, tlb->fullmm); > if (pte_dirty(ptent)) { > folio_mark_dirty(folio); > if (tlb_delay_rmap(tlb)) { > @@ -1567,8 +1564,17 @@ static inline void zap_present_pte(struct mmu_gather *tlb, > } > if (pte_young(ptent) && likely(vma_has_recency(vma))) > folio_mark_accessed(folio); > + rss[mm_counter(folio)]--; > + } else { > + /* We don't need up-to-date accessed/dirty bits. */ > + ptep_get_and_clear_full(mm, addr, pte, tlb->fullmm); > + rss[MM_ANONPAGES]--; > } > - rss[mm_counter(folio)]--; > + arch_check_zapped_pte(vma, ptent); Isn't the x86 (only) implementation of this relying on the dirty bit? So doesn't that imply you still need get_and_clear for anon? (And in hindsight I think that logic would apply to the previous patch too?) Impl: void arch_check_zapped_pte(struct vm_area_struct *vma, pte_t pte) { /* * Hardware before shadow stack can (rarely) set Dirty=1 * on a Write=0 PTE. So the below condition * only indicates a software bug when shadow stack is * supported by the HW. This checking is covered in * pte_shstk(). */ VM_WARN_ON_ONCE(!(vma->vm_flags & VM_SHADOW_STACK) && pte_shstk(pte)); } static inline bool pte_shstk(pte_t pte) { return cpu_feature_enabled(X86_FEATURE_SHSTK) && (pte_flags(pte) & (_PAGE_RW | _PAGE_DIRTY)) == _PAGE_DIRTY; } > + tlb_remove_tlb_entry(tlb, pte, addr); > + if (unlikely(userfaultfd_pte_wp(vma, ptent))) > + zap_install_uffd_wp_if_needed(vma, addr, pte, details, ptent); > + > if (!delay_rmap) { > folio_remove_rmap_pte(folio, page, vma); > if (unlikely(page_mapcount(page) < 0))