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 9EE2D3876AB for ; Thu, 26 Feb 2026 03:36:45 +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=1772077009; cv=none; b=HN5pKmrWto19dIHG1RFfuMKD26C6lWDwOnM3Nb7gCnaH99mECLJ16Kf1GLY4ZMBDav/DBGrovdaxEdp+0oGuugDtxefjX8CK7h5EZKfipLowigiUmakpUquT8dH0j56QEWoGhwx+EtTxy/HIsKqQ+0BTvGog98w1stjpXZvbFl4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772077009; c=relaxed/simple; bh=Tm8YMFoscU0xjc7iiBHCRTUVJsMHAuKDlTfYP+RFoag=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pYEhzTGR4TuU32DX7TYod+Qj3dztvLEVtFAyPgTW4vFCOcnc+h66XYKS93/k6ZZmi4ckeJj0lOjE1PujlKiwdGrN9egcq0PTPyq7UOLGpHnzxliG8/QdHmMMsFVfJ277cGEzmjNJaJ6ZX4GHWxtsvN/F7zo4KkVwna7rsEAHccU= 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=fHzmdP1w; 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="fHzmdP1w" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1772076997; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=xpzgBIQcGsuSWrw8v83C+dnRIF10MeSyjQBe5C87dLY=; b=fHzmdP1wAYcj+e1XFKvNFrkL4vA3B7+LB4/nspKAuHBq3Ypbfs5/psimcq4n425CywwqKFy9HG/bv98AZeZqdljCv8n+rVeymqQpx/ZyKJMXQjo4KCmdyBOB5bS/oHxfY/KKo3cq0/9AyKHReVr4LAZRGRIdO5X3B6B2jlaZU9w= Received: from 30.74.144.118(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WzpnG4Z_1772076994 cluster:ay36) by smtp.aliyun-inc.com; Thu, 26 Feb 2026 11:36:35 +0800 Message-ID: <41be3f15-2cc6-4ec3-beab-9a5c4da532a2@linux.alibaba.com> Date: Thu, 26 Feb 2026 11:36:33 +0800 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 1/5] mm: use inline helper functions instead of ugly macros To: "David Hildenbrand (Arm)" , akpm@linux-foundation.org Cc: catalin.marinas@arm.com, will@kernel.org, lorenzo.stoakes@oracle.com, ryan.roberts@arm.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, riel@surriel.com, harry.yoo@oracle.com, jannh@google.com, willy@infradead.org, baohua@kernel.org, dev.jain@arm.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, hannes@cmpxchg.org, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <1e90b26c-5934-47e4-a0ea-96fd8af45076@kernel.org> From: Baolin Wang In-Reply-To: <1e90b26c-5934-47e4-a0ea-96fd8af45076@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/25/26 9:56 PM, David Hildenbrand (Arm) wrote: > On 2/24/26 02:56, Baolin Wang wrote: >> People have already complained that these *_clear_young_notify() related >> macros are very ugly, so let's use inline helpers to make them more readable. > > Could it have been me :) Lorenzo and Matthew have also said they dislike these ugly macros:) >> In addition, I cannot implement these inline helper functions in the > > "We cannot implement ..." Sure. >> mmu_notifier.h file, because some arch-specific files will include the >> mmu_notifier.h, which introduces header compilation dependencies and causes >> build errors (e.g., arch/arm64/include/asm/tlbflush.h). Moreover, since >> these functions are only used in the mm, implementing these inline helpers >> in the mm/internal.h header seems reasonable. > > Agreed. if it compiles, all good. > >> >> Signed-off-by: Baolin Wang >> --- >> include/linux/mmu_notifier.h | 54 ------------------------------------ >> mm/internal.h | 53 +++++++++++++++++++++++++++++++++++ >> 2 files changed, 53 insertions(+), 54 deletions(-) >> >> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h >> index 07a2bbaf86e9..93894b90c8c1 100644 >> --- a/include/linux/mmu_notifier.h >> +++ b/include/linux/mmu_notifier.h >> @@ -515,55 +515,6 @@ static inline void mmu_notifier_range_init_owner( >> range->owner = owner; >> } >> >> -#define clear_flush_young_ptes_notify(__vma, __address, __ptep, __nr) \ >> -({ \ >> - int __young; \ >> - struct vm_area_struct *___vma = __vma; \ >> - unsigned long ___address = __address; \ >> - unsigned int ___nr = __nr; \ >> - __young = clear_flush_young_ptes(___vma, ___address, __ptep, ___nr); \ >> - __young |= mmu_notifier_clear_flush_young(___vma->vm_mm, \ >> - ___address, \ >> - ___address + \ >> - ___nr * PAGE_SIZE); \ >> - __young; \ >> -}) >> - >> -#define pmdp_clear_flush_young_notify(__vma, __address, __pmdp) \ >> -({ \ >> - int __young; \ >> - struct vm_area_struct *___vma = __vma; \ >> - unsigned long ___address = __address; \ >> - __young = pmdp_clear_flush_young(___vma, ___address, __pmdp); \ >> - __young |= mmu_notifier_clear_flush_young(___vma->vm_mm, \ >> - ___address, \ >> - ___address + \ >> - PMD_SIZE); \ >> - __young; \ >> -}) >> - >> -#define ptep_clear_young_notify(__vma, __address, __ptep) \ >> -({ \ >> - int __young; \ >> - struct vm_area_struct *___vma = __vma; \ >> - unsigned long ___address = __address; \ >> - __young = ptep_test_and_clear_young(___vma, ___address, __ptep);\ >> - __young |= mmu_notifier_clear_young(___vma->vm_mm, ___address, \ >> - ___address + PAGE_SIZE); \ >> - __young; \ >> -}) >> - >> -#define pmdp_clear_young_notify(__vma, __address, __pmdp) \ >> -({ \ >> - int __young; \ >> - struct vm_area_struct *___vma = __vma; \ >> - unsigned long ___address = __address; \ >> - __young = pmdp_test_and_clear_young(___vma, ___address, __pmdp);\ >> - __young |= mmu_notifier_clear_young(___vma->vm_mm, ___address, \ >> - ___address + PMD_SIZE); \ >> - __young; \ >> -}) >> - >> #else /* CONFIG_MMU_NOTIFIER */ >> >> struct mmu_notifier_range { >> @@ -651,11 +602,6 @@ static inline void mmu_notifier_subscriptions_destroy(struct mm_struct *mm) >> >> #define mmu_notifier_range_update_to_read_only(r) false >> >> -#define clear_flush_young_ptes_notify clear_flush_young_ptes >> -#define pmdp_clear_flush_young_notify pmdp_clear_flush_young >> -#define ptep_clear_young_notify ptep_test_and_clear_young >> -#define pmdp_clear_young_notify pmdp_test_and_clear_young >> - >> static inline void mmu_notifier_synchronize(void) >> { >> } >> diff --git a/mm/internal.h b/mm/internal.h >> index e0ef192b0be3..1ba175b8d4f1 100644 >> --- a/mm/internal.h >> +++ b/mm/internal.h >> @@ -11,6 +11,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -1789,4 +1790,56 @@ static inline int io_remap_pfn_range_complete(struct vm_area_struct *vma, >> return remap_pfn_range_complete(vma, addr, pfn, size, prot); >> } >> >> +#ifdef CONFIG_MMU_NOTIFIER >> +static inline int clear_flush_young_ptes_notify(struct vm_area_struct *vma, >> + unsigned long addr, pte_t *ptep, >> + unsigned int nr) > > Two tabs indent on the second line makes this fit into two lines. OK. > Same for the others. > > With that > > Acked-by: David Hildenbrand (Arm) Thanks. >> +{ >> + int young; >> + >> + young = clear_flush_young_ptes(vma, addr, ptep, nr); >> + young |= mmu_notifier_clear_flush_young(vma->vm_mm, addr, >> + addr + nr * PAGE_SIZE); >> + return young; >> +} >> + >> +static inline int pmdp_clear_flush_young_notify(struct vm_area_struct *vma, >> + unsigned long addr, pmd_t *pmdp) >> +{ >> + int young; >> + >> + young = pmdp_clear_flush_young(vma, addr, pmdp); >> + young |= mmu_notifier_clear_flush_young(vma->vm_mm, addr, addr + PMD_SIZE); >> + return young; >> +} >> + >> +static inline int ptep_clear_young_notify(struct vm_area_struct *vma, >> + unsigned long addr, pte_t *ptep) >> +{ >> + int young; >> + >> + young = ptep_test_and_clear_young(vma, addr, ptep); >> + young |= mmu_notifier_clear_young(vma->vm_mm, addr, addr + PAGE_SIZE); >> + return young; >> +} >> + >> +static inline int pmdp_clear_young_notify(struct vm_area_struct *vma, >> + unsigned long addr, pmd_t *pmdp) >> +{ >> + int young; >> + >> + young = pmdp_test_and_clear_young(vma, addr, pmdp); >> + young |= mmu_notifier_clear_young(vma->vm_mm, addr, addr + PMD_SIZE); >> + return young; >> +} > > Wonder why someone thought it would be a good idea to not include the > "test_and_", to make the function names inconsistent. Sounds reasonable. I can send a patch to rename them to: ptep_test_and_clear_young_notify pmdp_test_and_clear_young_notify