Re: [PATCH 2/6] mm: change to return bool for ptep_clear_flush_young()/clear_flush_young_ptes()
Baolin Wang <[email protected]>
| Newsgroups | org.kernel.vger.linux-parisc,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390,org.kvack.linux-mm,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <[email protected]> |
On 3/19/26 7:30 PM, Lorenzo Stoakes (Oracle) wrote: > On Thu, Mar 19, 2026 at 11:24:01AM +0800, Baolin Wang wrote: >> The ptep_clear_flush_young() and clear_flush_young_ptes() are used to clear >> the young flag and flush the TLB, returning whether the young flag was set. >> Change the return type to bool to make the intention clearer. >> >> Signed-off-by: Baolin Wang <[email protected]> > > Couple nits but LGTM, so: > > Reviewed-by: Lorenzo Stoakes (Oracle) <[email protected]> Thanks. >> --- >> arch/arm64/include/asm/pgtable.h | 15 +++++++-------- >> arch/arm64/mm/contpte.c | 4 ++-- >> arch/parisc/include/asm/pgtable.h | 2 +- >> arch/parisc/kernel/cache.c | 8 ++++---- >> arch/powerpc/include/asm/nohash/64/pgtable.h | 2 +- >> arch/riscv/include/asm/pgtable.h | 4 ++-- >> arch/s390/include/asm/pgtable.h | 4 ++-- >> arch/x86/include/asm/pgtable.h | 4 ++-- >> arch/x86/mm/pgtable.c | 4 ++-- >> include/linux/pgtable.h | 8 ++++---- >> mm/pgtable-generic.c | 7 ++++--- >> 11 files changed, 31 insertions(+), 31 deletions(-) >> >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >> index 8c651695204c..393a9d1873f6 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -1299,10 +1299,10 @@ static inline bool __ptep_test_and_clear_young(struct vm_area_struct *vma, >> return pte_young(pte); >> } >> >> -static inline int __ptep_clear_flush_young(struct vm_area_struct *vma, >> - unsigned long address, pte_t *ptep) >> +static inline bool __ptep_clear_flush_young(struct vm_area_struct *vma, >> + unsigned long address, pte_t *ptep) > > I mean this is subjective stuff but can we just put 2nd line 2 tabs indented > underneath? Makes it easier for changes like this to not propagate. > > Same comment for all of these! I usually use 2 tabs for indentation in the mm subsystem, but for other subsystems, I try to follow the existing style since I'm unsure of other maintainers' preferences:) Anyway, I can do this if no other objections.