Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755796Ab2BCPiM (ORCPT ); Fri, 3 Feb 2012 10:38:12 -0500 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:38676 "EHLO e06smtp17.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752420Ab2BCPiK (ORCPT ); Fri, 3 Feb 2012 10:38:10 -0500 Message-ID: <4F2BFF4C.5050905@de.ibm.com> Date: Fri, 03 Feb 2012 16:37:48 +0100 From: Gerald Schaefer Reply-To: gerald.schaefer@de.ibm.com User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: KOSAKI Motohiro CC: Hugh Dickins , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Martin Schwidefsky , Heiko Carstens , Andrea Arcangeli , Chris Wright , Izik Eidus , KAMEZAWA Hiroyuki Subject: Re: ksm/memory hotplug: lockdep warning for ksm_thread_mutex vs. (memory_chain).rwsem References: <4F2AB614.1060907@de.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit x-cbid: 12020315-0542-0000-0000-000000E442B6 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1450 Lines: 28 On 03.02.2012 00:00, KOSAKI Motohiro wrote: > 2012/2/2 Gerald Schaefer: >> Setting a memory block offline triggers the following lockdep warning. This >> looks exactly like the issue reported by Kosaki Motohiro in >> https://lkml.org/lkml/2010/10/25/110. Seems like the resulting commit a0b0f58cdd >> did not fix the lockdep warning. I'm able to reproduce it with current 3.3.0-rc2 >> as well as 2.6.37-rc4-00147-ga0b0f58. >> >> I'm not familiar with lockdep annotations, but I tried using down_read_nested() >> for (memory_chain).rwsem, similar to the mutex_lock_nested() which was >> introduced for ksm_thread_mutex, but that didn't help. > > Heh, interesting. Simple question, do you have any user visible buggy > behavior? or just false positive warn issue? > > *_nested() is just hacky trick. so, any change may break their lie. > Anyway I'd like to dig this one. thanks for reporting. There is no real deadlock and no user visible buggy behaviour, the memory is being offlined as requested. I think your conclusion from last time is still valid, that both locks are inside mem_hotplug_mutex and there can't be a deadlock. Question is how to convince lockdep of this. -- 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/