From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 47409CA5E for ; Tue, 16 Sep 2025 01:36:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757986581; cv=none; b=IFZ+8qLKd8vnJ045RWxZeTwjFwtI4xZj6kT0i9ccXzqbmYxfmvEfsXHNr/R0oqoMl9QViJOq2kFltffdZ0Sv4uwdHdTbW9b66E+TNyQjqLwNNU9z7ZaaiJvhgZy4Y4nXEoYfrz2NhyAgEbwqbG8CBR+Ci+d/ZFiFhf9Zu3kNi4Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757986581; c=relaxed/simple; bh=MXFcQ4ZGkmTx7rvXGFSKIdrds2mfeOFixKJ78OClczc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=JwipE3QIpDtni2lda2YVbdMUhgZWgm/1rKwXv+P6bc2B60uPP+DT0nKMsklGwIlOVUo53Lcb32f15g73Rg2GIc1yZJsqI6Ur9WSN8q1sQzLKNqYtO/+LFv0gos/xLve4tMzqNFR9gQ8Rx5H2z5WkCpDtZMZcfBWZeZ0qM67uRYE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=C7VvoLJd; arc=none smtp.client-ip=115.124.30.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="C7VvoLJd" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1757986568; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=iO9IyLuu+6VJGjLqKGfdYZOIt/8+8VRDHAroqFcBXb8=; b=C7VvoLJdP/9/F6aCbRQPn0x7onZzwChbaqsAlMUyvIusaqrosTaZ/3K/nu3vZ5tWlbtDUsD85WSYbwSU+pEDt4p6FW0lyFdskf5whrVB6cx3w6BEdsqU2b+ja21v5nd+NOGQaXBGxIRGlVklIwrd74ld7Le2HJGDXCK5ZKIwTx8= Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0Wo6JU5v_1757986565 cluster:ay36) by smtp.aliyun-inc.com; Tue, 16 Sep 2025 09:36:06 +0800 From: "Huang, Ying" To: David Hildenbrand Cc: Catalin Marinas , Will Deacon , Andrew Morton , Lorenzo Stoakes , Vlastimil Babka , Zi Yan , Baolin Wang , Ryan Roberts , Yang Shi , "Christoph Lameter (Ampere)" , Dev Jain , Barry Song , Anshuman Khandual , Yicong Yang , Kefeng Wang , Kevin Brodsky , Yin Fengwei , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 1/2] mm: add spurious fault fixing support for huge pmd In-Reply-To: <8c51da7a-7370-4678-96a3-7cd6eaf0db62@redhat.com> (David Hildenbrand's message of "Mon, 15 Sep 2025 13:08:09 +0200") References: <20250915032946.33203-1-ying.huang@linux.alibaba.com> <20250915032946.33203-2-ying.huang@linux.alibaba.com> <8c51da7a-7370-4678-96a3-7cd6eaf0db62@redhat.com> Date: Tue, 16 Sep 2025 09:36:03 +0800 Message-ID: <87frcn6uws.fsf@DESKTOP-5N7EMDA> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Hi, David, Thanks for review! David Hildenbrand writes: > On 15.09.25 05:29, Huang Ying wrote: >> In the current kernel, there is spurious fault fixing support for pte, >> but not for huge pmd because no architectures need it. But in the >> next patch in the series, we will change the write protection fault >> handling logic on arm64, so that some stale huge pmd entries may >> remain in the TLB. These entries need to be flushed via the huge pmd >> spurious fault fixing mechanism. >> Signed-off-by: Huang Ying >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Andrew Morton >> Cc: David Hildenbrand >> Cc: Lorenzo Stoakes >> Cc: Vlastimil Babka >> Cc: Zi Yan >> Cc: Baolin Wang >> Cc: Ryan Roberts >> Cc: Yang Shi >> Cc: "Christoph Lameter (Ampere)" >> Cc: Dev Jain >> Cc: Barry Song >> Cc: Anshuman Khandual >> Cc: Yicong Yang >> Cc: Kefeng Wang >> Cc: Kevin Brodsky >> Cc: Yin Fengwei >> Cc: linux-arm-kernel@lists.infradead.org >> Cc: linux-kernel@vger.kernel.org >> Cc: linux-mm@kvack.org >> --- > > [...] > >> int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct >> *src_mm, >> @@ -1857,7 +1861,20 @@ void huge_pmd_set_accessed(struct vm_fault *vmf) >> if (unlikely(!pmd_same(*vmf->pmd, vmf->orig_pmd))) >> goto unlock; >> - touch_pmd(vmf->vma, vmf->address, vmf->pmd, write); >> + if (!touch_pmd(vmf->vma, vmf->address, vmf->pmd, write)) { >> + /* Skip spurious TLB flush for retried page fault */ >> + if (vmf->flags & FAULT_FLAG_TRIED) >> + goto unlock; >> + /* >> + * This is needed only for protection faults but the arch code >> + * is not yet telling us if this is a protection fault or not. >> + * This still avoids useless tlb flushes for .text page faults >> + * with threads. >> + */ > > Can we instead just remove these comments and simplly say "see > handle_pte_fault()" Sure. >> + if (vmf->flags & FAULT_FLAG_WRITE) >> + flush_tlb_fix_spurious_fault_pmd(vmf->vma, vmf->address, >> + vmf->pmd); >> + } > > Okay, In the PTE case, we call flush_tlb_fix_spurious_fault() during > write faults if ptep_set_access_flags() returned "0". > > You are calling flush_tlb_fix_spurious_fault_pmd() during a write > fault when pmdp_set_access_flags() returned "0" as well. > > In general, LGTM, but I would just let touch_pmd() return the value of > pmdp_set_access_flags() instead and add a quick comment for > touch_pmd() what the return value means. Sure. --- Best Regards, Huang, Ying