Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1238979 > unrolled thread

[PATCH] mm/mmap.c: Remove redundant vma looping

Back to article view | Back to linux.kernel

Contents

  [PATCH] mm/mmap.c: Remove redundant vma looping Chen Gang <xili_gchen_5257@hotmail.com> - 2015-10-03 21:40 +0200
    Re: [PATCH] mm/mmap.c: Remove redundant vma looping Richard Weinberger <richard.weinberger@gmail.com> - 2015-10-03 22:10 +0200
      Re: [PATCH] mm/mmap.c: Remove redundant vma looping Chen Gang <xili_gchen_5257@hotmail.com> - 2015-10-04 07:00 +0200
        Re: [PATCH] mm/mmap.c: Remove redundant vma looping Andrea Arcangeli <aarcange@redhat.com> - 2015-10-04 19:30 +0200
          RE: [PATCH] mm/mmap.c: Remove redundant vma looping Chen Gang <xili_gchen_5257@hotmail.com> - 2015-10-05 14:30 +0200

#1238979 — [PATCH] mm/mmap.c: Remove redundant vma looping

[Multipart message — attachments visible in raw view] — view raw

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)
-- 
1.9.3


Chen Gang

Open, share, and attitude like air, water, and life which God blessed
 		 	   		  

[toc] | [next] | [standalone]

#1238983

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239035

On 10/4/15 04:09, Richard Weinberger wrote:
> 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.
>

Oh, really. Thanks.

> 
> git blame often explains funky code. :-)
> 

Next, I shall check the git log before make patches, each time. :-)

Theoretically, the lock and unlock need to be symmetric, if we have to
lock f_mapping all firstly, then lock all anon_vma, probably, we also
need to unlock anon_vma all, then unlock all f_mapping.


Thanks.
-- 
Chen Gang (陈刚)

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239159

Hello Chen,

On Sun, Oct 04, 2015 at 12:55:29PM +0800, Chen Gang wrote:
> Theoretically, the lock and unlock need to be symmetric, if we have to
> lock f_mapping all firstly, then lock all anon_vma, probably, we also
> need to unlock anon_vma all, then unlock all f_mapping.

They don't need to be symmetric because the unlocking order doesn't
matter. To avoid lock inversion deadlocks it is enough to enforce the
lock order.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239502

PiBGcm9tOiBhYXJjYW5nZUByZWRoYXQuY29tCj4KPiBIZWxsbyBDaGVuLAo+Cj4gT24gU3VuLCBP
Y3QgMDQsIDIwMTUgYXQgMTI6NTU6MjlQTSArMDgwMCwgQ2hlbiBHYW5nIHdyb3RlOgo+PiBUaGVv
cmV0aWNhbGx5LCB0aGUgbG9jayBhbmQgdW5sb2NrIG5lZWQgdG8gYmUgc3ltbWV0cmljLCBpZiB3
ZSBoYXZlIHRvCj4+IGxvY2sgZl9tYXBwaW5nIGFsbCBmaXJzdGx5LCB0aGVuIGxvY2sgYWxsIGFu
b25fdm1hLCBwcm9iYWJseSwgd2UgYWxzbwo+PiBuZWVkIHRvIHVubG9jayBhbm9uX3ZtYSBhbGws
IHRoZW4gdW5sb2NrIGFsbCBmX21hcHBpbmcuCj4KPiBUaGV5IGRvbid0IG5lZWQgdG8gYmUgc3lt
bWV0cmljIGJlY2F1c2UgdGhlIHVubG9ja2luZyBvcmRlciBkb2Vzbid0Cj4gbWF0dGVyLiBUbyBh
dm9pZCBsb2NrIGludmVyc2lvbiBkZWFkbG9ja3MgaXQgaXMgZW5vdWdoIHRvIGVuZm9yY2UgdGhl
Cj4gbG9jayBvcmRlci4KCk9LLCB0aGFua3MuIEkgc2hhbGwgY29udGludWUgdG8gZmluZCBhbm90
aGVyIHBhdGNoZXMuIDotKQoKLS0KQ2hlbiBHYW5nCgpPcGVuLCBzaGFyZSwgYW5kIGF0dGl0dWRl
IGxpa2UgYWlyLCB3YXRlciwgYW5kIGxpZmUgd2hpY2ggR29kIGJsZXNzZWQKIAkJIAkgICAJCSAg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web