From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932883AbZJFOmG (ORCPT ); Tue, 6 Oct 2009 10:42:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932852AbZJFOmF (ORCPT ); Tue, 6 Oct 2009 10:42:05 -0400 Received: from smtp.polymtl.ca ([132.207.4.11]:38726 "EHLO smtp.polymtl.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932862AbZJFOmE (ORCPT ); Tue, 6 Oct 2009 10:42:04 -0400 Message-Id: <20091006144043.378971387@polymtl.ca> References: <20091006143727.868480435@polymtl.ca> User-Agent: quilt/0.46-1 Date: Tue, 06 Oct 2009 10:37:32 -0400 From: Mathieu Desnoyers To: akpm@linux-foundation.org, Ingo Molnar , linux-kernel@vger.kernel.org, "Paul E. McKenney" Cc: Mathieu Desnoyers , cl@linux-foundation.org, linux-mm@kvack.org Subject: [patch 4/4] vunmap: Fix racy use of rcu_head Content-Disposition: inline; filename=vunmap-fix-teardown.patch X-Poly-FromMTA: (test.casi.polymtl.ca [132.207.72.60]) at Tue, 6 Oct 2009 14:40:45 +0000 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: [] ? __call_rcu+0x181/0x190 [] ? __call_rcu+0x181/0x190 [] ? warn_slowpath_common+0x79/0xd0 [] ? rcu_free_va+0x0/0x10 [] ? __call_rcu+0x181/0x190 [] ? __purge_vmap_area_lazy+0x1a8/0x1e0 [] ? free_unmap_vmap_area_noflush+0x74/0x80 [] ? remove_vm_area+0x2e/0x80 [] ? __vunmap+0x45/0xf0 [] ? ltt_statedump_start+0x7b6/0x820 [ltt_sta] [] ? arch_imv_update+0x16a/0x2f0 [] ? imv_update_range+0x53/0xa0 [] ? _module_imv_update+0x4b/0x60 [] ? module_imv_update+0x15/0x30 [] ? marker_probe_register+0x149/0xb90 [] ? ltt_vtrace+0x0/0x8c0 [] ? ltt_marker_connect+0xd0/0x150 [] ? marker_enable_write+0xec/0x120 [] ? __dentry_open+0x268/0x350 [] ? marker_probe_cb+0x9c/0x170 [] ? marker_probe_cb+0x9c/0x170 [] ? vfs_write+0xcb/0x170 [] ? sys_write+0x64/0x130 [] ? system_call_fastpath+0x16/0x1b ---[ end trace ef92443e716fa199 ]--- ------------[ cut here ]------------ Signed-off-by: Mathieu Desnoyers CC: cl@linux-foundation.org CC: mingo@elte.hu CC: "Paul E. McKenney" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with ESMTP id 4280F6B004D for ; Tue, 6 Oct 2009 10:41:01 -0400 (EDT) Message-Id: <20091006144043.378971387@polymtl.ca> References: <20091006143727.868480435@polymtl.ca> Date: Tue, 06 Oct 2009 10:37:32 -0400 From: Mathieu Desnoyers Subject: [patch 4/4] vunmap: Fix racy use of rcu_head Content-Disposition: inline; filename=vunmap-fix-teardown.patch Sender: owner-linux-mm@kvack.org To: akpm@linux-foundation.org, Ingo Molnar , linux-kernel@vger.kernel.org, "Paul E. McKenney" Cc: Mathieu Desnoyers , cl@linux-foundation.org, linux-mm@kvack.org List-ID: 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: [] ? __call_rcu+0x181/0x190 [] ? __call_rcu+0x181/0x190 [] ? warn_slowpath_common+0x79/0xd0 [] ? rcu_free_va+0x0/0x10 [] ? __call_rcu+0x181/0x190 [] ? __purge_vmap_area_lazy+0x1a8/0x1e0 [] ? free_unmap_vmap_area_noflush+0x74/0x80 [] ? remove_vm_area+0x2e/0x80 [] ? __vunmap+0x45/0xf0 [] ? ltt_statedump_start+0x7b6/0x820 [ltt_sta] [] ? arch_imv_update+0x16a/0x2f0 [] ? imv_update_range+0x53/0xa0 [] ? _module_imv_update+0x4b/0x60 [] ? module_imv_update+0x15/0x30 [] ? marker_probe_register+0x149/0xb90 [] ? ltt_vtrace+0x0/0x8c0 [] ? ltt_marker_connect+0xd0/0x150 [] ? marker_enable_write+0xec/0x120 [] ? __dentry_open+0x268/0x350 [] ? marker_probe_cb+0x9c/0x170 [] ? marker_probe_cb+0x9c/0x170 [] ? vfs_write+0xcb/0x170 [] ? sys_write+0x64/0x130 [] ? system_call_fastpath+0x16/0x1b ---[ end trace ef92443e716fa199 ]--- ------------[ cut here ]------------ Signed-off-by: Mathieu Desnoyers CC: cl@linux-foundation.org CC: mingo@elte.hu CC: "Paul E. McKenney" 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: email@kvack.org