Messages in this thread | | | Date | Sat, 3 Oct 2015 22:09:15 +0200 | Subject | Re: [PATCH] mm/mmap.c: Remove redundant vma looping | From | Richard Weinberger <> |
| |
On Sat, Oct 3, 2015 at 9:38 PM, Chen Gang <xili_gchen_5257@hotmail.com> wrote: > From 36dbcc145819655682f80efd49e72b01515b4e9a Mon Sep 17 00:00:00 2001 > From: Chen Gang <gang.chen.5i5j@gmail.com> > Date: Sun, 4 Oct 2015 03:22:41 +0800 > Subject: [PATCH] mm/mmap.c: Remove redundant vma looping > > vma->vm_file->f_mapping and vma->anon_vma are shared with the same vma > looping, so merge them. > > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> > --- > mm/mmap.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 8393580..f7c1631 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -3201,9 +3201,7 @@ int mm_take_all_locks(struct mm_struct *mm) > goto out_unlock; > if (vma->vm_file && vma->vm_file->f_mapping) > vm_lock_mapping(mm, vma->vm_file->f_mapping); > - } > > - for (vma = mm->mmap; vma; vma = vma->vm_next) { > if (signal_pending(current)) > goto out_unlock; > if (vma->anon_vma)
With that change you're reintroducing an issue. Please see: commit 7cd5a02f54f4c9d16cf7fdffa2122bc73bb09b43 Author: Peter Zijlstra <a.p.zijlstra@chello.nl> Date: Mon Aug 11 09:30:25 2008 +0200
mm: fix mm_take_all_locks() locking order
Lockdep spotted:
======================================================= [ INFO: possible circular locking dependency detected ] 2.6.27-rc1 #270 ------------------------------------------------------- qemu-kvm/2033 is trying to acquire lock: (&inode->i_data.i_mmap_lock){----}, at: [<ffffffff802996cc>] mm_take_all_locks+0xc2/0xea
but task is already holding lock: (&anon_vma->lock){----}, at: [<ffffffff8029967a>] mm_take_all_locks+0x70/0xea
which lock already depends on the new lock.
git blame often explains funky code. :-)
-- Thanks, //richard
| |