Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756896Ab0LAUNj (ORCPT ); Wed, 1 Dec 2010 15:13:39 -0500 Received: from smtp-out.google.com ([74.125.121.35]:39599 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755655Ab0LAUNi (ORCPT ); Wed, 1 Dec 2010 15:13:38 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; b=lgfWy66mW1Qa3pF+az+1xR0bhJU8VmwwgAm5f5fhxf63ZCiDHiVGPHJcB2IHxDs6+s 3WI3zXAfzul50Asszy3w== Date: Wed, 1 Dec 2010 12:13:32 -0800 (PST) From: Hugh Dickins X-X-Sender: hughd@tigran.mtv.corp.google.com To: KOSAKI Motohiro cc: Andrew Morton , Andrea Arcangeli , Andi Kleen , LKML , linux-mm , KAMEZAWA Hiroyuki Subject: Re: [PATCH 2/2] ksm: annotate ksm_thread_mutex is no deadlock source In-Reply-To: <20101201143008.ABCE.A69D9226@jp.fujitsu.com> Message-ID: References: <20101026163218.B7BF.A69D9226@jp.fujitsu.com> <20101201143008.ABCE.A69D9226@jp.fujitsu.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4283 Lines: 99 On Wed, 1 Dec 2010, KOSAKI Motohiro wrote: > > commit 62b61f611e(ksm: memory hotremove migration only) made following > new lockdep warning. > > ======================================================= > [ INFO: possible circular locking dependency detected ] > ------------------------------------------------------- > bash/1621 is trying to acquire lock: > ((memory_chain).rwsem){.+.+.+}, at: [] > __blocking_notifier_call_chain+0x69/0xc0 > > but task is already holding lock: > (ksm_thread_mutex){+.+.+.}, at: [] > ksm_memory_callback+0x3a/0xc0 > > which lock already depends on the new lock. > > the existing dependency chain (in reverse order) is: > > -> #1 (ksm_thread_mutex){+.+.+.}: > [] lock_acquire+0xaa/0x140 > [] __mutex_lock_common+0x44/0x3f0 > [] mutex_lock_nested+0x48/0x60 > [] ksm_memory_callback+0x3a/0xc0 > [] notifier_call_chain+0x8c/0xe0 > [] __blocking_notifier_call_chain+0x7e/0xc0 > [] blocking_notifier_call_chain+0x16/0x20 > [] memory_notify+0x1b/0x20 > [] remove_memory+0x1cc/0x5f0 > [] memory_block_change_state+0xfd/0x1a0 > [] store_mem_state+0xe2/0xf0 > [] sysdev_store+0x20/0x30 > [] sysfs_write_file+0xe6/0x170 > [] vfs_write+0xc8/0x190 > [] sys_write+0x54/0x90 > [] system_call_fastpath+0x16/0x1b > > -> #0 ((memory_chain).rwsem){.+.+.+}: > [] __lock_acquire+0x155a/0x1600 > [] lock_acquire+0xaa/0x140 > [] down_read+0x51/0xa0 > [] __blocking_notifier_call_chain+0x69/0xc0 > [] blocking_notifier_call_chain+0x16/0x20 > [] memory_notify+0x1b/0x20 > [] remove_memory+0x56e/0x5f0 > [] memory_block_change_state+0xfd/0x1a0 > [] store_mem_state+0xe2/0xf0 > [] sysdev_store+0x20/0x30 > [] sysfs_write_file+0xe6/0x170 > [] vfs_write+0xc8/0x190 > [] sys_write+0x54/0x90 > [] system_call_fastpath+0x16/0x1b > > But it's false positive. Both memory_chain.rwsem and ksm_thread_mutex > have outer lock (mem_hotplug_mutex). then, they can't make deadlock. > > Thus, This patch annotate ksm_thread_mutex is not deadlock source. > > Signed-off-by: KOSAKI Motohiro Thank you (I assume it does the job, I've not yet checked). My only issue with this is that the comment you added below tells a different story from the fuller comment you give above. Maybe change it to: * mutex_lock_nested() is necessary because lockdep was alarmed that * here we take ksm_thread_mutex inside notifier chain mutex, and * later take notifier chain mutex inside ksm_thread_mutex to unlock * it: but that's safe because both are inside mem_hotplug_mutex. Acked-by: Hugh Dickins > --- > mm/ksm.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/mm/ksm.c b/mm/ksm.c > index 65ab5c7..5aa4900 100644 > --- a/mm/ksm.c > +++ b/mm/ksm.c > @@ -1724,8 +1724,10 @@ static int ksm_memory_callback(struct notifier_block *self, > /* > * Keep it very simple for now: just lock out ksmd and > * MADV_UNMERGEABLE while any memory is going offline. > + * Mutex_lock_nested() is necessary to tell that > + * ksm_thread_mutex is not unlocked here intentionally. > */ > - mutex_lock(&ksm_thread_mutex); > + mutex_lock_nested(&ksm_thread_mutex, SINGLE_DEPTH_NESTING); > break; > > case MEM_OFFLINE: > -- > 1.6.5.2 -- 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/