All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	cl@linux-foundation.org, linux-mm@kvack.org
Subject: [patch 4/4] vunmap: Fix racy use of rcu_head
Date: Tue, 06 Oct 2009 10:37:32 -0400	[thread overview]
Message-ID: <20091006144043.378971387@polymtl.ca> (raw)
In-Reply-To: 20091006143727.868480435@polymtl.ca

[-- Attachment #1: vunmap-fix-teardown.patch --]
[-- Type: text/plain, Size: 3613 bytes --]

Repetitive use of vmap/vunmap on the same address triggers this bug.

Simplest fix: directly kfree the data structure rather than doing it lazily.

Impact:
(-) slight slowdown on vunmap
(+) stop messing up rcu callback lists ;)

Caught it with DEBUG_RCU_HEAD, running LTTng armall/disarmall in loops.
Immediate values (with breakpoint-ipi scheme) are still using vunmap.

------------[ cut here ]------------
WARNING: at kernel/rcutree.c:1199 __call_rcu+0x181/0x190()
Hardware name: X7DAL
Modules linked in: loop ltt_statedump ltt_userspace_event ipc_tr]
Pid: 4527, comm: ltt-armall Not tainted 2.6.30.9-trace #30
Call Trace:
 [<ffffffff8027b181>] ? __call_rcu+0x181/0x190
 [<ffffffff8027b181>] ? __call_rcu+0x181/0x190
 [<ffffffff8023a6a9>] ? warn_slowpath_common+0x79/0xd0
 [<ffffffff802b4890>] ? rcu_free_va+0x0/0x10
 [<ffffffff8027b181>] ? __call_rcu+0x181/0x190
 [<ffffffff802b5298>] ? __purge_vmap_area_lazy+0x1a8/0x1e0
 [<ffffffff802b59d4>] ? free_unmap_vmap_area_noflush+0x74/0x80
 [<ffffffff802b5a0e>] ? remove_vm_area+0x2e/0x80
 [<ffffffff802b5b35>] ? __vunmap+0x45/0xf0
 [<ffffffffa002e826>] ? ltt_statedump_start+0x7b6/0x820 [ltt_sta]
 [<ffffffff8068978a>] ? arch_imv_update+0x16a/0x2f0
 [<ffffffff8027dd13>] ? imv_update_range+0x53/0xa0
 [<ffffffff8026235b>] ? _module_imv_update+0x4b/0x60
 [<ffffffff80262385>] ? module_imv_update+0x15/0x30
 [<ffffffff80280049>] ? marker_probe_register+0x149/0xb90
 [<ffffffff8040c8e0>] ? ltt_vtrace+0x0/0x8c0
 [<ffffffff80409330>] ? ltt_marker_connect+0xd0/0x150
 [<ffffffff8040f8dc>] ? marker_enable_write+0xec/0x120
 [<ffffffff802c6cb8>] ? __dentry_open+0x268/0x350
 [<ffffffff80280b2c>] ? marker_probe_cb+0x9c/0x170
 [<ffffffff80280b2c>] ? marker_probe_cb+0x9c/0x170
 [<ffffffff802c973b>] ? vfs_write+0xcb/0x170
 [<ffffffff802c9984>] ? sys_write+0x64/0x130
 [<ffffffff8020beeb>] ? system_call_fastpath+0x16/0x1b
---[ end trace ef92443e716fa199 ]---
------------[ cut here ]------------

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: cl@linux-foundation.org
CC: mingo@elte.hu
CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
CC: linux-mm@kvack.org
CC: akpm@linux-foundation.org
---
 mm/vmalloc.c |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

Index: linux-2.6-lttng/mm/vmalloc.c
===================================================================
--- linux-2.6-lttng.orig/mm/vmalloc.c	2009-10-06 09:37:04.000000000 -0400
+++ linux-2.6-lttng/mm/vmalloc.c	2009-10-06 09:37:56.000000000 -0400
@@ -417,13 +417,6 @@ overflow:
 	return va;
 }
 
-static void rcu_free_va(struct rcu_head *head)
-{
-	struct vmap_area *va = container_of(head, struct vmap_area, rcu_head);
-
-	kfree(va);
-}
-
 static void __free_vmap_area(struct vmap_area *va)
 {
 	BUG_ON(RB_EMPTY_NODE(&va->rb_node));
@@ -431,7 +424,7 @@ static void __free_vmap_area(struct vmap
 	RB_CLEAR_NODE(&va->rb_node);
 	list_del_rcu(&va->list);
 
-	call_rcu(&va->rcu_head, rcu_free_va);
+	kfree(va);
 }
 
 /*
@@ -757,13 +750,6 @@ static struct vmap_block *new_vmap_block
 	return vb;
 }
 
-static void rcu_free_vb(struct rcu_head *head)
-{
-	struct vmap_block *vb = container_of(head, struct vmap_block, rcu_head);
-
-	kfree(vb);
-}
-
 static void free_vmap_block(struct vmap_block *vb)
 {
 	struct vmap_block *tmp;
@@ -778,7 +764,7 @@ static void free_vmap_block(struct vmap_
 	BUG_ON(tmp != vb);
 
 	free_unmap_vmap_area_noflush(vb->va);
-	call_rcu(&vb->rcu_head, rcu_free_vb);
+	kfree(vb);
 }
 
 static void *vb_alloc(unsigned long size, gfp_t gfp_mask)

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	cl@linux-foundation.org, linux-mm@kvack.org
Subject: [patch 4/4] vunmap: Fix racy use of rcu_head
Date: Tue, 06 Oct 2009 10:37:32 -0400	[thread overview]
Message-ID: <20091006144043.378971387@polymtl.ca> (raw)
In-Reply-To: 20091006143727.868480435@polymtl.ca

[-- Attachment #1: vunmap-fix-teardown.patch --]
[-- Type: text/plain, Size: 3839 bytes --]

Repetitive use of vmap/vunmap on the same address triggers this bug.

Simplest fix: directly kfree the data structure rather than doing it lazily.

Impact:
(-) slight slowdown on vunmap
(+) stop messing up rcu callback lists ;)

Caught it with DEBUG_RCU_HEAD, running LTTng armall/disarmall in loops.
Immediate values (with breakpoint-ipi scheme) are still using vunmap.

------------[ cut here ]------------
WARNING: at kernel/rcutree.c:1199 __call_rcu+0x181/0x190()
Hardware name: X7DAL
Modules linked in: loop ltt_statedump ltt_userspace_event ipc_tr]
Pid: 4527, comm: ltt-armall Not tainted 2.6.30.9-trace #30
Call Trace:
 [<ffffffff8027b181>] ? __call_rcu+0x181/0x190
 [<ffffffff8027b181>] ? __call_rcu+0x181/0x190
 [<ffffffff8023a6a9>] ? warn_slowpath_common+0x79/0xd0
 [<ffffffff802b4890>] ? rcu_free_va+0x0/0x10
 [<ffffffff8027b181>] ? __call_rcu+0x181/0x190
 [<ffffffff802b5298>] ? __purge_vmap_area_lazy+0x1a8/0x1e0
 [<ffffffff802b59d4>] ? free_unmap_vmap_area_noflush+0x74/0x80
 [<ffffffff802b5a0e>] ? remove_vm_area+0x2e/0x80
 [<ffffffff802b5b35>] ? __vunmap+0x45/0xf0
 [<ffffffffa002e826>] ? ltt_statedump_start+0x7b6/0x820 [ltt_sta]
 [<ffffffff8068978a>] ? arch_imv_update+0x16a/0x2f0
 [<ffffffff8027dd13>] ? imv_update_range+0x53/0xa0
 [<ffffffff8026235b>] ? _module_imv_update+0x4b/0x60
 [<ffffffff80262385>] ? module_imv_update+0x15/0x30
 [<ffffffff80280049>] ? marker_probe_register+0x149/0xb90
 [<ffffffff8040c8e0>] ? ltt_vtrace+0x0/0x8c0
 [<ffffffff80409330>] ? ltt_marker_connect+0xd0/0x150
 [<ffffffff8040f8dc>] ? marker_enable_write+0xec/0x120
 [<ffffffff802c6cb8>] ? __dentry_open+0x268/0x350
 [<ffffffff80280b2c>] ? marker_probe_cb+0x9c/0x170
 [<ffffffff80280b2c>] ? marker_probe_cb+0x9c/0x170
 [<ffffffff802c973b>] ? vfs_write+0xcb/0x170
 [<ffffffff802c9984>] ? sys_write+0x64/0x130
 [<ffffffff8020beeb>] ? system_call_fastpath+0x16/0x1b
---[ end trace ef92443e716fa199 ]---
------------[ cut here ]------------

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: cl@linux-foundation.org
CC: mingo@elte.hu
CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
CC: linux-mm@kvack.org
CC: akpm@linux-foundation.org
---
 mm/vmalloc.c |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

Index: linux-2.6-lttng/mm/vmalloc.c
===================================================================
--- linux-2.6-lttng.orig/mm/vmalloc.c	2009-10-06 09:37:04.000000000 -0400
+++ linux-2.6-lttng/mm/vmalloc.c	2009-10-06 09:37:56.000000000 -0400
@@ -417,13 +417,6 @@ overflow:
 	return va;
 }
 
-static void rcu_free_va(struct rcu_head *head)
-{
-	struct vmap_area *va = container_of(head, struct vmap_area, rcu_head);
-
-	kfree(va);
-}
-
 static void __free_vmap_area(struct vmap_area *va)
 {
 	BUG_ON(RB_EMPTY_NODE(&va->rb_node));
@@ -431,7 +424,7 @@ static void __free_vmap_area(struct vmap
 	RB_CLEAR_NODE(&va->rb_node);
 	list_del_rcu(&va->list);
 
-	call_rcu(&va->rcu_head, rcu_free_va);
+	kfree(va);
 }
 
 /*
@@ -757,13 +750,6 @@ static struct vmap_block *new_vmap_block
 	return vb;
 }
 
-static void rcu_free_vb(struct rcu_head *head)
-{
-	struct vmap_block *vb = container_of(head, struct vmap_block, rcu_head);
-
-	kfree(vb);
-}
-
 static void free_vmap_block(struct vmap_block *vb)
 {
 	struct vmap_block *tmp;
@@ -778,7 +764,7 @@ static void free_vmap_block(struct vmap_
 	BUG_ON(tmp != vb);
 
 	free_unmap_vmap_area_noflush(vb->va);
-	call_rcu(&vb->rcu_head, rcu_free_vb);
+	kfree(vb);
 }
 
 static void *vb_alloc(unsigned long size, gfp_t gfp_mask)

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2009-10-06 14:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-06 14:37 [patch 0/4] DEBUG_RCU_HEAD: Debug and fix racy call_rcu() users Mathieu Desnoyers
2009-10-06 14:37 ` [patch 1/4] kernel call_rcu usage: initialize rcu_head structures Mathieu Desnoyers
2009-10-06 15:19   ` [patch 1/4] kernel call_rcu usage: initialize rcu_head structures (v2) Mathieu Desnoyers
2009-10-06 14:37 ` [patch 2/4] tree rcu: Add debug RCU head option Mathieu Desnoyers
2009-10-06 15:54   ` Eric Dumazet
2009-10-06 16:09     ` Mathieu Desnoyers
2009-10-06 16:17       ` Eric Dumazet
2009-10-06 16:35         ` Mathieu Desnoyers
2009-10-06 14:37 ` [patch 3/4] markers call_rcu usage: initialize rcu_head structures Mathieu Desnoyers
2009-10-06 14:37 ` Mathieu Desnoyers [this message]
2009-10-06 14:37   ` [patch 4/4] vunmap: Fix racy use of rcu_head Mathieu Desnoyers
2009-10-06 15:23   ` Mathieu Desnoyers
2009-10-06 15:23     ` Mathieu Desnoyers
2009-10-06 16:43   ` Christoph Lameter
2009-10-06 16:43     ` Christoph Lameter
2009-10-06 17:33     ` Mathieu Desnoyers
2009-10-06 17:33       ` Mathieu Desnoyers
2009-10-07  4:20 ` [patch 0/4] DEBUG_RCU_HEAD: Debug and fix racy call_rcu() users Paul E. McKenney
2009-10-07 12:36   ` Mathieu Desnoyers
2009-10-12 18:07 ` Ingo Molnar
2009-10-12 18:30   ` Mathieu Desnoyers
2009-10-12 18:37     ` Ingo Molnar
2009-10-12 18:56       ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091006144043.378971387@polymtl.ca \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.