Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757386Ab0KLBX3 (ORCPT ); Thu, 11 Nov 2010 20:23:29 -0500 Received: from mail-yx0-f174.google.com ([209.85.213.174]:56694 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755614Ab0KLBX2 (ORCPT ); Thu, 11 Nov 2010 20:23:28 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Cd6PZ4SOYiMua49G8U8OqOe3ShYyaAyB1a6zBzKKfBUe10kjTI0mIcgw27D8VT/uqp XHGhaf48l4Y4UcRvqM93/iPIs2X/ehGyfY1F2pLejFhyzuHE65xR1BUftqEhbwpwANuV gjrt3rjF2+2Rp1wixHhkaMQUMTuk0bFAHZb/U= Date: Thu, 11 Nov 2010 17:23:15 -0800 From: Dmitry Torokhov To: Vladislav Bolkhovitin Cc: Boaz Harrosh , Greg KH , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, scst-devel , James Bottomley , Andrew Morton , FUJITA Tomonori , Mike Christie , Vu Pham , Bart Van Assche , James Smart , Joe Eykholt , Andy Yan , Chetan Loke , Hannes Reinecke , Richard Sharpe , Daniel Henrique Debonzi Subject: Re: [PATCH 8/19]: SCST SYSFS interface implementation Message-ID: <20101112012315.GE17097@core.coreip.homeip.net> References: <20101022175624.GA13640@kroah.com> <4CC1DAA2.7030602@vlnb.net> <20101022185437.GA9103@kroah.com> <4CD8566D.1020202@vlnb.net> <20101109002829.GA22633@kroah.com> <4CD9A9B8.70708@vlnb.net> <4CDA6CD4.3010308@panasas.com> <4CDAFE6E.7050200@vlnb.net> <4CDBBE80.40908@panasas.com> <4CDC56F9.9040601@vlnb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CDC56F9.9040601@vlnb.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2242 Lines: 64 On Thu, Nov 11, 2010 at 11:50:01PM +0300, Vladislav Bolkhovitin wrote: > Boaz Harrosh, on 11/11/2010 12:59 PM wrote: > >> static void x_release(struct kobject *kobj) > > Yes. Precisely speaking, of its kobj_type. > > > This one is put on the kobj.release Right? > > > >> { > >> struct object_x *x; > >> struct completion *c; > >> > >> x = container_of(kobj, struct object_x, kobj); > >> c = x->release_completion; > >> kfree(x); > >> complete_all(c); > >> } > >> > > > > I don't see the unregister of the object_x.kobj, where do > > you do this one in x_release or del_object below? > > Which unregister? Put for object_x.kobj is in del_object() > > >> void del_object(struct object_x *x) > >> { > >> DECLARE_COMPLETION_ONSTACK(completion); > >> > >> ... > >> x->release_completion = &completion; > >> kobject_put(&x->kobj); > > > > This put might not be the last put on the object, IOs in flight > > and/or open files might have extra reference on the object. > > We release our initial ref, and below wait for all operations > > to complete. (Is there a matter of timeout like files not closing?) > > This is the last internal put. All other references are from outsiders. > So, we are waiting for all them to put before we go on. > The question is why do you need to wait here? I presume it is module unloading path, but then it is quite bad - you can easily wedge your subsystem if you make something to take a reference to your kobject while module is ytying to be unloaded. Back when sysfs attributes tied kobjects the easiest thing was to do: rmmod < / sys/devices/..../attribute If you are done with the kobject - just proceed with what you were doing and let it die its own peaceful death some time later. You just need to make sure release code sticks around to free it and your subsystem core can be tasked with this. Use module counter to prevent unloading of the subsystem core until all kobjects belonging to the subsystem are destroyed. -- Dmitry -- 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/