Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932777AbZJFReU (ORCPT ); Tue, 6 Oct 2009 13:34:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932728AbZJFReT (ORCPT ); Tue, 6 Oct 2009 13:34:19 -0400 Received: from tomts5.bellnexxia.net ([209.226.175.25]:51555 "EHLO tomts5-srv.bellnexxia.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932638AbZJFReS (ORCPT ); Tue, 6 Oct 2009 13:34:18 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAKcYy0pMROOX/2dsb2JhbACBUdI+hCoE Date: Tue, 6 Oct 2009 13:33:40 -0400 From: Mathieu Desnoyers To: Christoph Lameter Cc: nickpiggin@yahoo.com.au, akpm@linux-foundation.org, Ingo Molnar , linux-kernel@vger.kernel.org, "Paul E. McKenney" , linux-mm@kvack.org Subject: Re: [patch 4/4] vunmap: Fix racy use of rcu_head Message-ID: <20091006173340.GA25502@Krystal> References: <20091006143727.868480435@polymtl.ca> <20091006144043.378971387@polymtl.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.6.27.31-grsec (i686) X-Uptime: 13:26:17 up 49 days, 4:15, 2 users, load average: 0.31, 0.35, 0.23 User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3378 Lines: 88 * Christoph Lameter (cl@linux-foundation.org) wrote: > On Tue, 6 Oct 2009, Mathieu Desnoyers wrote: > > > Simplest fix: directly kfree the data structure rather than doing it lazily. > > The delay is necessary as far as I can tell for performance reasons. But > Nick was the last one fiddling around with the subsystem as far as I > remember. CCing him. May be he has a minute to think about a fix that > preserved performance. > Thanks, More info on the problem: I added a check in alloc_vmap_area() at: va = kmalloc_node(sizeof(struct vmap_area), gfp_mask & GFP_RECLAIM_MASK, node); WARN_ON(va->rcu_head.debug == LIST_POISON1); (memory allocation debugging is off in my config) I used this along with my new call rcu debug patch to check if memory is reallocated before the callback (doing kfree) is executed. It triggers this: WARNING: at mm/vmalloc.c:343 alloc_vmap_area+0x305/0x340() Hardware name: X7DAL Modules linked in: loop ltt_statedump ltt_userspace_event ipc_tr] Pid: 5584, comm: ltt-disarmall Not tainted 2.6.30.9-trace #41 Call Trace: [] ? alloc_vmap_area+0x305/0x340 [] ? alloc_vmap_area+0x305/0x340 [] ? warn_slowpath_common+0x79/0xd0 [] ? alloc_vmap_area+0x305/0x340 [] ? default_wake_function+0x0/0x10 [] ? __get_vm_area_node+0xc9/0x1d0 [] ? sys_getsockopt+0x85/0x160 [] ? ltt_vtrace+0x0/0x8d0 [] ? get_vm_area_caller+0x2d/0x40 [] ? arch_imv_update+0x10e/0x2f0 [] ? vmap+0x4a/0x80 [] ? arch_imv_update+0x10e/0x2f0 [] ? get_tracepoint+0x25d/0x290 [] ? imv_update_range+0x53/0xa0 [] ? tracepoint_update_probes+0x21/0x30 [] ? tracepoint_probe_update_all+0x83/0x100 [] ? marker_update_probes+0x21/0x40 [] ? ltt_vtrace+0x0/0x8d0 [] ? marker_probe_unregister+0xad/0x130 [] ? ltt_marker_disconnect+0xdc/0x120 [] ? marker_enable_write+0x112/0x120 [] ? _spin_unlock+0x10/0x30 [] ? mnt_drop_write+0x76/0x180 [] ? do_filp_open+0x2cd/0xa00 [] ? tty_write+0x221/0x270 [] ? vfs_write+0xcb/0x170 [] ? sys_write+0x64/0x130 [] ? system_call_fastpath+0x16/0x1b ---[ end trace 7ef506680d7a9e26 ]--- Could it be that: static void __free_vmap_area(struct vmap_area *va) { BUG_ON(RB_EMPTY_NODE(&va->rb_node)); rb_erase(&va->rb_node, &vmap_area_root); RB_CLEAR_NODE(&va->rb_node); list_del_rcu(&va->list); call_rcu(&va->rcu_head, rcu_free_va); } (especially clearing from the rb tree and va list) allows reallocation of the node by kmalloc_node before its reclamation (only done later by rcu_free_va) ? Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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/