Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762436AbYAHQ5R (ORCPT ); Tue, 8 Jan 2008 11:57:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753938AbYAHQ5A (ORCPT ); Tue, 8 Jan 2008 11:57:00 -0500 Received: from twin.jikos.cz ([213.151.79.26]:54922 "EHLO twin.jikos.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756593AbYAHQ47 (ORCPT ); Tue, 8 Jan 2008 11:56:59 -0500 Date: Tue, 8 Jan 2008 17:54:02 +0100 (CET) From: Jiri Kosina To: David Brownell cc: Alan Stern , Dave Young , Greg KH , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH 01/12] Use mutex instead of semaphore in driver core In-Reply-To: <200712292242.47960.david-b@pacbell.net> Message-ID: References: <200712292242.47960.david-b@pacbell.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 882 Lines: 22 On Sat, 29 Dec 2007, David Brownell wrote: > > There's no way to remove these, which means there's no way to prevent > > lockdep from issuing a warning. > There may be no *efficient* way to do that. If it tracked every lock > individually these false alarms could go away; but that would increase > the overhead to create and destroy such locks too. And it would also do something completely different compared to what lockdep is doing now. The point is being able to spot the potential deadlock before it actually happens. If you track individual instances instead of classess, you are out of luck with this. -- Jiri Kosina -- 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/