Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750918AbWINQA3 (ORCPT ); Thu, 14 Sep 2006 12:00:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750922AbWINQA2 (ORCPT ); Thu, 14 Sep 2006 12:00:28 -0400 Received: from twin.jikos.cz ([213.151.79.26]:57249 "EHLO twin.jikos.cz") by vger.kernel.org with ESMTP id S1750917AbWINQA2 (ORCPT ); Thu, 14 Sep 2006 12:00:28 -0400 Date: Thu, 14 Sep 2006 18:00:21 +0200 (CEST) From: Jiri Kosina To: Dmitry Torokhov cc: lkml , Arjan van de Ven Subject: Re: [PATCH 0/3] Synaptics - fix lockdep warnings In-Reply-To: Message-ID: References: <200609132200.51342.dtor@insightbb.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1100 Lines: 29 On Thu, 14 Sep 2006, Dmitry Torokhov wrote: > Not yet ;) Is there a way to hide the depth in the spinlock/mutex > structure itself so that initialization code could do > spin_lock_init_nested() and spare the rest of the code from that > knowledge? (shortened CC list a bit) In fact I am not sure what you mean. On every lock and unlock operation, in case of recursive locking (which our case is), you have to provide class identifier, which is used to distinguish if the lock is of the same instance, or a different one (deeper or higher in the locking hierarchy). There is no way how spin_lock() or mutex_lock() can know this "automatically", you always have to provide the nesting level from outside, as it depends on the ordering hierarchy, which locking primitives are totally unaware of. Or did I misunderstand you? Thanks, -- JiKos. - 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/