Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753448AbYASJhI (ORCPT ); Sat, 19 Jan 2008 04:37:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754303AbYASJgq (ORCPT ); Sat, 19 Jan 2008 04:36:46 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]:18252 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753334AbYASJgo (ORCPT ); Sat, 19 Jan 2008 04:36:44 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ffERsk+QjETidmNW0mhGsMZfDr3nB0EyVu/nqjJBvYbQeB/+0YQQdPx8wGudMAM4iuvNoHOszetSb1vdu9k6okf82jDBa+vdYkPUSwdSz9LVIstb6PuuWIU5AmHj3g8v6KqRq2uJrSu+BPlSy7ymEfCrQu5to8E4W9acaQp6ke8= Message-ID: <4791C555.9050205@gmail.com> Date: Sat, 19 Jan 2008 10:39:33 +0100 From: Jarek Poplawski User-Agent: Icedove 1.5.0.14pre (X11/20071020) MIME-Version: 1.0 To: Dave Young CC: Kay Sievers , Alan Stern , Greg KH , stefanr@s5r6.in-berlin.de, David Brownell , Kernel development list Subject: Re: [PATCH 7/7] driver-core : convert semaphore to mutex in struct class References: <20080117232626.GC2905@ami.dom.local> <3ae72650801171755k85c4245i3b4c46a84ae8f52d@mail.gmail.com> <1200626323.5640.21.camel@lov.site> <20080118073836.GA1703@ff.dom.local> <20080118082327.GC1703@ff.dom.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1389 Lines: 35 Dave Young wrote, On 01/18/2008 10:07 AM: > On Jan 18, 2008 4:23 PM, Jarek Poplawski wrote: >> On Fri, Jan 18, 2008 at 03:48:02PM +0800, Dave Young wrote: ... >>> 1) Using CLASS_NORMAL/CLASS_PARENT/CLASS_CHILD will be enough. >>> or >>> 2) Simply add SINGLE_LEVEL_NESTING in class_device_add and other >>> class_device functions because it is the only possible nest-lock place >>> as I know. Dave, after looking a bit at this it seems you could be "mostly" right with this 2). Maybe I've missed something (I didn't verify this yet), but it looks like +1 level (SINGLE_LEVEL_NESTING) could be needed in: class_device_add() (as you did), but probably also class_device_del() and class_device_destroy(). ...But, there seems to be "little" problem, if there is used this recursion with: class_intf->add()/remove() in class_device_add()/del()?! Then Kay is right about possibility of deeper nesting. If this path is really used, and any of these class_device_* functions with locking are called, then this patch couldn't work like this. So, there is a question: how deep nesting is currently used here? Regards, Jarek P. -- 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/