On Fri, Nov 01, 2013 at 07:44:29PM +0800, Yuanhan Liu wrote: > commit 012f18004da33ba672e3c60838cc4898126174d3 > Author: Rik van Riel <[email protected]> > Date: Mon Aug 9 17:18:40 2010 -0700 > > mm: always lock the root (oldest) anon_vma > > Always (and only) lock the root (oldest) anon_vma whenever we do something > in an anon_vma. The recently introduced anon_vma scalability is due to > the rmap code scanning only the VMAs that need to be scanned. Many common > operations still took the anon_vma lock on the root anon_vma, so always > taking that lock is not expected to introduce any scalability issues. > > However, always taking the same lock does mean we only need to take one > lock, which means rmap_walk on pages from any anon_vma in the vma is > excluded from occurring during an munmap, expand_stack or other operation > that needs to exclude rmap_walk and similar functions. > > Also add the proper locking to vma_adjust. > > Signed-off-by: Rik van Riel <[email protected]> > Tested-by: Larry Woodman <[email protected]> > Acked-by: Larry Woodman <[email protected]> > Reviewed-by: Minchan Kim <[email protected]> > Reviewed-by: KAMEZAWA Hiroyuki <[email protected]> > Acked-by: Mel Gorman <[email protected]> > Acked-by: Linus Torvalds <[email protected]> > Signed-off-by: Andrew Morton <[email protected]> > Signed-off-by: Linus Torvalds <[email protected]>
Right that commit did. I'm still not sure why you change both the locking proper and the locking primitive used in one patch set. Also, changing the locking proper requires a very detailed explanation on why it is correct; we've had far too many 'fun' issues with the anon_vma locking in the past. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
