From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753725AbdLHLBx (ORCPT ); Fri, 8 Dec 2017 06:01:53 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:36968 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753684AbdLHLBp (ORCPT ); Fri, 8 Dec 2017 06:01:45 -0500 Date: Fri, 8 Dec 2017 11:01:40 +0000 From: Catalin Marinas To: chenjiankang Cc: Will Deacon , Yisheng Xie , qiuxishi@huawei.com, linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com Subject: Re: a racy access flag clearing warning when calling mmap system call Message-ID: <20171208110140.6tx272scqvelkum2@armageddon.cambridge.arm.com> References: <20171201131832.GB14823@arm.com> <3d44f029-7870-f560-786f-f3a55b3ec0c6@huawei.com> <20171207132303.GF31900@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 08, 2017 at 11:19:52AM +0800, chenjiankang wrote: > 在 2017/12/7 21:23, Will Deacon 写道: > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > > index 149d05fb9421..8fe103b1e101 100644 > > --- a/arch/arm64/include/asm/pgtable.h > > +++ b/arch/arm64/include/asm/pgtable.h > > @@ -42,6 +42,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > > > extern void __pte_error(const char *file, int line, unsigned long val); > > extern void __pmd_error(const char *file, int line, unsigned long val); > > @@ -207,9 +209,6 @@ static inline void set_pte(pte_t *ptep, pte_t pte) > > } > > } > > > > -struct mm_struct; > > -struct vm_area_struct; > > - > > extern void __sync_icache_dcache(pte_t pteval, unsigned long addr); > > > > /* > > @@ -238,7 +237,8 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, > > * hardware updates of the pte (ptep_set_access_flags safely changes > > * valid ptes without going through an invalid entry). > > */ > > - if (pte_valid(*ptep) && pte_valid(pte)) { > > + if (IS_ENABLED(CONFIG_DEBUG_VM) && pte_valid(*ptep) && pte_valid(pte) && > > + (mm == current->active_mm || atomic_read(&mm->mm_users) > 1)) { > > VM_WARN_ONCE(!pte_young(pte), > > "%s: racy access flag clearing: 0x%016llx -> 0x%016llx", > > __func__, pte_val(*ptep), pte_val(pte)); [...] > From the print information, the only difference between pte and ptep is the PTE_SPECIAL bit. > And the the PTE access bit is all zero. > diff below. Whether the access bit of the new ptep should be judged to eliminate the > false positive? [...] > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > index 2987d5a..3c1b0c6 100644 > --- a/arch/arm64/include/asm/pgtable.h > +++ b/arch/arm64/include/asm/pgtable.h > @@ -206,7 +206,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, > * valid ptes without going through an invalid entry). > */ > if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) && pte_valid(*ptep)) { > - VM_WARN_ONCE(!pte_young(pte), > + VM_WARN_ONCE(!pte_young(pte) && pte_young(*ptep), > "%s: racy access flag clearing: %016llx -> %016llx", > __func__, pte_val(*ptep), pte_val(pte)); It's actually the other way around: *ptep being "old" (AF = 0) could at any point be made "young" by the hardware (AF = 1). This is racing with the software update which keeps the AF bit 0. -- Catalin