lkml.org 
[lkml]   [2017]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: a racy access flag clearing warning when calling mmap system call
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 <asm/cmpxchg.h>
> > #include <asm/fixmap.h>
> > #include <linux/mmdebug.h>
> > +#include <linux/mm_types.h>
> > +#include <linux/sched.h>
> >
> > 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

\
 
 \ /
  Last update: 2017-12-08 12:02    [W:0.047 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site