lkml.org 
[lkml]   [2010]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/2] Fix migration races in rmap_walk() V3
    On Sat, May 01, 2010 at 03:51:10PM +0200, Johannes Weiner wrote:
    > On Fri, Apr 30, 2010 at 08:28:53PM +0200, Andrea Arcangeli wrote:
    > > Subject: adapt mprotect to anon_vma chain semantics
    > >
    > > From: Andrea Arcangeli <aarcange@redhat.com>
    > >
    > > wait_split_huge_page interface changed.
    > >
    > > Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    > > ---
    > >
    > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
    > > --- a/mm/huge_memory.c
    > > +++ b/mm/huge_memory.c
    > > @@ -929,7 +929,7 @@ int change_huge_pmd(struct vm_area_struc
    > > if (likely(pmd_trans_huge(*pmd))) {
    > > if (unlikely(pmd_trans_splitting(*pmd))) {
    > > spin_unlock(&mm->page_table_lock);
    > > - wait_split_huge_page(vma->anon_vma, pmd);
    > > + wait_split_huge_page(mm, pmd);
    >
    > That makes mprotect-vma-arg obsolete, I guess.

    Well it's needed for flush_tlb_range. Also normally we could run a
    single invlpg on x86 to invalidate huge pmd tlbs, but I read some
    errata for some x86, and I didn't want to take risks plus this is
    common code so I can't just run a common code flush_tlb_page. In
    mincore_huge_pmd probably we could pass vma->vm_mm instead of vma (as
    there is not flush_tlb_range), I can change it if you prefer.


    \
     
     \ /
      Last update: 2010-05-03 17:35    [W:3.003 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site