From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Kroah-Hartman Subject: Re: [RFC 1/2] core: Add generic object registry implementation Date: Fri, 7 Nov 2014 08:31:43 -0800 Message-ID: <20141107163143.GD10256@kroah.com> References: <1415118568-18771-1-git-send-email-thierry.reding@gmail.com> <20141104163845.GA369@kroah.com> <20141105091351.GA12033@ulmo> <20141106021815.GA17253@kroah.com> <20141106102531.GI26297@ulmo> <20141106161321.GB14873@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) by gabe.freedesktop.org (Postfix) with ESMTP id 36DB16E96B for ; Fri, 7 Nov 2014 08:31:44 -0800 (PST) Content-Disposition: inline In-Reply-To: <20141106161321.GB14873@ulmo.nvidia.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thierry Reding Cc: Daniel Vetter , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCBOb3YgMDYsIDIwMTQgYXQgMDU6MTM6MjRQTSArMDEwMCwgVGhpZXJyeSBSZWRpbmcg d3JvdGU6Cj4gT24gVGh1LCBOb3YgMDYsIDIwMTQgYXQgMTE6MjU6MzJBTSArMDEwMCwgVGhpZXJy eSBSZWRpbmcgd3JvdGU6Cj4gPiBPbiBXZWQsIE5vdiAwNSwgMjAxNCBhdCAwNjoxODoxNVBNIC0w ODAwLCBHcmVnIEtyb2FoLUhhcnRtYW4gd3JvdGU6Cj4gWy4uLl0KPiA+ID4gU3VyZSwgZG9jdW1l bnQgaXQgYmV0dGVyIGlmIHlvdSB3YW50LCBidXQgSSB0aGluayBzb21ldGhpbmcgbmVlZHMgdG8g YmUKPiA+ID4gZG9uZSBkaWZmZXJlbnRseSBpZiBhdCBhbGwgcG9zc2libGUuCj4gPiAKPiA+IHRy eV9tb2R1bGVfZ2V0KCkgaXMgdGhlIG9ubHkgd2F5IEkga25vdyBvZiB0aGF0IGVuc3VyZXMgdGhh dCB0aGUgY29kZSBvZgo+ID4gYSBtb2R1bGUgc3RheXMgYXJvdW5kLiBFdmVyeXRpbWUgd2UgZ2l2 ZSBvdXQgYSBuZXcgcmVmZXJlbmNlIHRvIGEgcmVjb3JkCj4gPiB3ZSBhbHNvIG5lZWQgdG8gaW5j cmVtZW50IHRoZSBtb2R1bGUgcmVmZXJlbmNlIGNvdW50IGFjY29yZGluZ2x5IHRvIG1ha2UKPiA+ IHN1cmUgdGhlIHVuZGVybHlpbmcgY29kZSBkb2Vzbid0IGdvIGF3YXkgYWxsIG9mIGEgc3VkZGVu Lgo+ID4gCj4gPiBJIGd1ZXNzIHRoYXQncyBub3QgZW50aXJlbHkgYWNjdXJhdGUuIFRoZSBtb2R1 bGUgcmVmZXJlbmNlIGNvdW50IGRvZXNuJ3QKPiA+IGhhdmUgdG8gYmUgaW5jcmVtZW50IGZvciBl dmVyeSByZWNvcmQgcmVmZXJlbmNlLCBpdCBvbmx5IG5lZWRzIHRvIHRyYWNrCj4gPiBlYWNoIHJl Y29yZC4gU28gdGhlIHRyeV9tb2R1bGVfZ2V0KCkgYW5kIG1vZHVsZV9wdXQoKSBjb3VsZCBtb3Zl IGludG8KPiA+IHJlZ2lzdHJ5X2FkZCgpIGFuZCByZWdpc3RyeV9nZXQoKSwgcmVzcGVjdGl2ZWx5 LiBCdXQgdGhlIC0+b3duZXIgZmllbGQKPiA+IHdvdWxkIHN0aWxsIGJlIGluIHRoZSByZWNvcmQg c3RydWN0dXJlLgo+IAo+IE9uIGZ1cnRoZXIgdGhvdWdodCBJIGRvbid0IHRoaW5rIHRoaXMgd2ls bCB3b3JrIGVpdGhlci4gR2l2ZW4gdGhhdCB0aGUKPiByZWNvcmQgY2FuIGJlIHJlbW92ZWQgZnJv bSB0aGUgcmVnaXN0cnkgd2hpbGUgc29tZWJvZHkgZWxzZSBzdGlsbCBoYXMgYQo+IHJlZmVyZW5j ZSB0byBpdCwgdGhlIG1vZHVsZSBvd25pbmcgdGhlIHJlY29yZCBtdXN0IHN0YXkgYXJvdW5kIGFz IGxvbmcKPiBhcyB0aGVyZSdzIGEgcmVmZXJlbmNlIHRvIHRoZSByZWNvcmQuCj4gCj4gTWF5YmUg dGhlIG1vZHVsZSByZWZlcmVuY2UgY291bnQgbmVlZHMgdG8gYmUgaW5jcmVtZW50ZWQgd2hlbiB0 aGUgcmVjb3JkCj4gaXMgaW5pdGlhbGl6ZWQgYW5kIGRlY3JlbWVudGVkIHdoZW4gdGhlIHJlY29y ZCBpcyByZWxlYXNlZC4KClRoZSBtb2R1bGUgcmVmZXJlbmNlIGNvdW50IHdpbGwgbmV2ZXIgd29y ayBhcyBpdCBpcyByYWN5ICh5b3UgY2FuJ3QgaGF2ZQp0aGUgbW9kdWxlIGl0c2VsZiBkbyB0aGUg aW5jcmVtZW50aW5nLCB3aGljaCBpcyB3aGF0IGlzIGhhcHBlbmluZyBoZXJlKS4KCkknZCBhcmd1 ZSB0aGF0IHRoZSBtb2R1bGUgcmVmZXJlbmNlIGlzbid0IG5lZWRlZCBhdCBhbGwsIGJlY2F1c2Ug aWYgdGhlCm1vZHVsZSBzaHV0cyBkb3duIGFuZCB3YW50cyB0byBiZSByZW1vdmVkLCBpdCB3aWxs IGhhdmUgcHJvcGVybHkgY2xlYW5lZAp1cCBhbGwgb2YgaXRzIGRhdGEgc3RydWN0dXJlcyBhbHJl YWR5LCByaWdodD8gIFNvIHdoeSB1c2UgaXQ/CgpncmVnIGstaApfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1k ZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752323AbaKGQbq (ORCPT ); Fri, 7 Nov 2014 11:31:46 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:37341 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750993AbaKGQbo (ORCPT ); Fri, 7 Nov 2014 11:31:44 -0500 Date: Fri, 7 Nov 2014 08:31:43 -0800 From: Greg Kroah-Hartman To: Thierry Reding Cc: Daniel Vetter , David Herrmann , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 1/2] core: Add generic object registry implementation Message-ID: <20141107163143.GD10256@kroah.com> References: <1415118568-18771-1-git-send-email-thierry.reding@gmail.com> <20141104163845.GA369@kroah.com> <20141105091351.GA12033@ulmo> <20141106021815.GA17253@kroah.com> <20141106102531.GI26297@ulmo> <20141106161321.GB14873@ulmo.nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141106161321.GB14873@ulmo.nvidia.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 06, 2014 at 05:13:24PM +0100, Thierry Reding wrote: > On Thu, Nov 06, 2014 at 11:25:32AM +0100, Thierry Reding wrote: > > On Wed, Nov 05, 2014 at 06:18:15PM -0800, Greg Kroah-Hartman wrote: > [...] > > > Sure, document it better if you want, but I think something needs to be > > > done differently if at all possible. > > > > try_module_get() is the only way I know of that ensures that the code of > > a module stays around. Everytime we give out a new reference to a record > > we also need to increment the module reference count accordingly to make > > sure the underlying code doesn't go away all of a sudden. > > > > I guess that's not entirely accurate. The module reference count doesn't > > have to be increment for every record reference, it only needs to track > > each record. So the try_module_get() and module_put() could move into > > registry_add() and registry_get(), respectively. But the ->owner field > > would still be in the record structure. > > On further thought I don't think this will work either. Given that the > record can be removed from the registry while somebody else still has a > reference to it, the module owning the record must stay around as long > as there's a reference to the record. > > Maybe the module reference count needs to be incremented when the record > is initialized and decremented when the record is released. The module reference count will never work as it is racy (you can't have the module itself do the incrementing, which is what is happening here). I'd argue that the module reference isn't needed at all, because if the module shuts down and wants to be removed, it will have properly cleaned up all of its data structures already, right? So why use it? greg k-h