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: Tue, 4 Nov 2014 08:38:45 -0800 Message-ID: <20141104163845.GA369@kroah.com> References: <1415118568-18771-1-git-send-email-thierry.reding@gmail.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 550226E5C6 for ; Tue, 4 Nov 2014 08:39:55 -0800 (PST) Content-Disposition: inline In-Reply-To: <1415118568-18771-1-git-send-email-thierry.reding@gmail.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 T24gVHVlLCBOb3YgMDQsIDIwMTQgYXQgMDU6Mjk6MjdQTSArMDEwMCwgVGhpZXJyeSBSZWRpbmcg d3JvdGU6Cj4gRnJvbTogVGhpZXJyeSBSZWRpbmcgPHRyZWRpbmdAbnZpZGlhLmNvbT4KPiAKPiBB ZGQgYSBnZW5lcmljIGltcGxlbWVudGF0aW9uIG9mIGFuIG9iamVjdCByZWdpc3RyeS4gVGhpcyB0 YXJnZXRzIGRyaXZlcnMKPiBhbmQgc3Vic3lzdGVtcyB0aGF0IHByb3ZpZGUgYXV4aWxpYXJ5IG9i amVjdHMgdGhhdCBvdGhlciBkcml2ZXJzIG5lZWQgdG8KPiBsb29rIHVwLiBUaGUgZ29hbCBpcyB0 byBwdXQgdGhlIGRpZmZpY3VsdCBwYXJ0cyAoa2VlcCBvYmplY3QgcmVmZXJlbmNlcywKPiBtb2R1 bGUgdXNhZ2UgY291bnQsIC4uLikgaW50byBjb3JlIGNvZGUgc28gdGhhdCBpbmRpdmlkdWFsIHN1 YnN5c3RlbXMgZG8KPiBub3QgaGF2ZSB0byBkZWFsIHdpdGggdGhlbS4KPiAKPiBUaGUgaW50ZW50 aW9uIGlzIGZvciBzdWJzeXN0ZW1zIHRvIGluc3RhbnRpYXRlIGEgc3RydWN0IHJlZ2lzdHJ5IGFu ZCB1c2UKPiBhIHN0cnVjdCByZWdpc3RyeV9yZWNvcmQgZW1iZWRkZWQgaW50byBhIHN1YnN5c3Rl bS1zcGVjaWZpYyBzdHJ1Y3R1cmUgdG8KPiBwcm92aWRlIGEgc3Vic3lzdGVtLXNwZWNpZmljIEFQ SSBhcm91bmQgdGhhdC4KPiAKPiBTaWduZWQtb2ZmLWJ5OiBUaGllcnJ5IFJlZGluZyA8dHJlZGlu Z0BudmlkaWEuY29tPgo+IC0tLQo+ICBkcml2ZXJzL2Jhc2UvTWFrZWZpbGUgICAgfCAgIDIgKy0K PiAgZHJpdmVycy9iYXNlL3JlZ2lzdHJ5LmMgIHwgMTQ3ICsrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrCj4gIGluY2x1ZGUvbGludXgvcmVnaXN0cnkuaCB8ICA2 MiArKysrKysrKysrKysrKysrKysrKwo+ICAzIGZpbGVzIGNoYW5nZWQsIDIxMCBpbnNlcnRpb25z KCspLCAxIGRlbGV0aW9uKC0pCj4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL2Jhc2UvcmVn aXN0cnkuYwo+ICBjcmVhdGUgbW9kZSAxMDA2NDQgaW5jbHVkZS9saW51eC9yZWdpc3RyeS5oCj4g Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvYmFzZS9NYWtlZmlsZSBiL2RyaXZlcnMvYmFzZS9NYWtl ZmlsZQo+IGluZGV4IDUzYzNmZTFhZWIyOS4uMjUwMjYyZDFhZjJjIDEwMDY0NAo+IC0tLSBhL2Ry aXZlcnMvYmFzZS9NYWtlZmlsZQo+ICsrKyBiL2RyaXZlcnMvYmFzZS9NYWtlZmlsZQo+IEBAIC00 LDcgKzQsNyBAQCBvYmoteQkJCTo9IGNvbXBvbmVudC5vIGNvcmUubyBidXMubyBkZC5vIHN5c2Nv cmUubyBcCj4gIAkJCSAgIGRyaXZlci5vIGNsYXNzLm8gcGxhdGZvcm0ubyBcCj4gIAkJCSAgIGNw dS5vIGZpcm13YXJlLm8gaW5pdC5vIG1hcC5vIGRldnJlcy5vIFwKPiAgCQkJICAgYXR0cmlidXRl X2NvbnRhaW5lci5vIHRyYW5zcG9ydF9jbGFzcy5vIFwKPiAtCQkJICAgdG9wb2xvZ3kubyBjb250 YWluZXIubyBwcm9wZXJ0eS5vCj4gKwkJCSAgIHRvcG9sb2d5Lm8gY29udGFpbmVyLm8gcHJvcGVy dHkubyByZWdpc3RyeS5vCj4gIG9iai0kKENPTkZJR19ERVZUTVBGUykJKz0gZGV2dG1wZnMubwo+ ICBvYmotJChDT05GSUdfRE1BX0NNQSkgKz0gZG1hLWNvbnRpZ3VvdXMubwo+ICBvYmoteQkJCSs9 IHBvd2VyLwo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2Jhc2UvcmVnaXN0cnkuYyBiL2RyaXZlcnMv YmFzZS9yZWdpc3RyeS5jCj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQKPiBpbmRleCAwMDAwMDAwMDAw MDAuLjlmNTEwZjYyMzdiNwo+IC0tLSAvZGV2L251bGwKPiArKysgYi9kcml2ZXJzL2Jhc2UvcmVn aXN0cnkuYwo+IEBAIC0wLDAgKzEsMTQ3IEBACj4gKy8qCj4gKyAqIENvcHlyaWdodCAoQykgMjAx NCwgTlZJRElBIENvcnBvcmF0aW9uLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KPiArICoKPiArICog VGhpcyBmaWxlIGlzIHJlbGVhc2VkIHVuZGVyIHRoZSBHUEwgdjIuCj4gKyAqLwo+ICsKPiArI2lu Y2x1ZGUgPGxpbnV4L2RldmljZS5oPgo+ICsjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+Cj4gKyNp bmNsdWRlIDxsaW51eC9yZWdpc3RyeS5oPgo+ICsKPiArc3RhdGljIGlubGluZSBzdHJ1Y3QgcmVn aXN0cnlfcmVjb3JkICp0b19yZWdpc3RyeV9yZWNvcmQoc3RydWN0IGtyZWYgKmtyZWYpCj4gK3sK PiArCXJldHVybiBjb250YWluZXJfb2Yoa3JlZiwgc3RydWN0IHJlZ2lzdHJ5X3JlY29yZCwga3Jl Zik7Cj4gK30KPiArCj4gK3N0YXRpYyB2b2lkIHJlZ2lzdHJ5X3JlY29yZF9yZWxlYXNlKHN0cnVj dCBrcmVmICprcmVmKQo+ICt7Cj4gKwlzdHJ1Y3QgcmVnaXN0cnlfcmVjb3JkICpyZWNvcmQgPSB0 b19yZWdpc3RyeV9yZWNvcmQoa3JlZik7Cj4gKwo+ICsJcmVjb3JkLT5yZWxlYXNlKHJlY29yZCk7 Cj4gK30KPiArCj4gKy8qKgo+ICsgKiByZWdpc3RyeV9yZWNvcmRfaW5pdCAtIGluaXRpYWxpemUg YSByZWdpc3RyeSByZWNvcmQKPiArICogQHJlY29yZDogcmVjb3JkIHRvIGluaXRpYWxpemUKPiAr ICoKPiArICogU2V0cyB1cCBpbnRlcm5hbCBmaWVsZHMgb2YgdGhlIHJlZ2lzdHJ5IHJlY29yZCBz byB0aGF0IGl0IGNhbiBzdWJzZXF1ZW50bHkKPiArICogYmUgYWRkZWQgdG8gYSByZWdpc3RyeS4K PiArICovCj4gK3ZvaWQgcmVnaXN0cnlfcmVjb3JkX2luaXQoc3RydWN0IHJlZ2lzdHJ5X3JlY29y ZCAqcmVjb3JkKQo+ICt7Cj4gKwlJTklUX0xJU1RfSEVBRCgmcmVjb3JkLT5saXN0KTsKPiArCWty ZWZfaW5pdCgmcmVjb3JkLT5rcmVmKTsKPiArfQo+ICsKPiArLyoqCj4gKyAqIHJlZ2lzdHJ5X3Jl Y29yZF9yZWYgLSByZWZlcmVuY2Ugb24gdGhlIHJlZ2lzdHJ5IHJlY29yZAo+ICsgKiBAcmVjb3Jk OiByZWNvcmQgdG8gcmVmZXJlbmNlCj4gKyAqCj4gKyAqIEluY3JlYXNlcyB0aGUgcmVmZXJlbmNl IGNvdW50IG9uIHRoZSByZWNvcmQgYW5kIHJldHVybnMgYSBwb2ludGVyIHRvIGl0Lgo+ICsgKgo+ ICsgKiBSZXR1cm46IEEgcG9pbnRlciB0byB0aGUgcmVjb3JkIG9uIHN1Y2Nlc3Mgb3IgTlVMTCBv biBmYWlsdXJlLgo+ICsgKi8KPiArc3RydWN0IHJlZ2lzdHJ5X3JlY29yZCAqcmVnaXN0cnlfcmVj b3JkX3JlZihzdHJ1Y3QgcmVnaXN0cnlfcmVjb3JkICpyZWNvcmQpCj4gK3sKPiArCWlmICghcmVj b3JkKQo+ICsJCXJldHVybiBOVUxMOwo+ICsKPiArCS8qCj4gKwkgKiBSZWZ1c2UgdG8gZ2l2ZSBv dXQgYW55IG1vcmUgcmVmZXJlbmNlcyBpZiB0aGUgbW9kdWxlIG93bmluZyB0aGUKPiArCSAqIHJl Y29yZCBpcyBiZWluZyByZW1vdmVkLgo+ICsJICovCj4gKwlpZiAoIXRyeV9tb2R1bGVfZ2V0KHJl Y29yZC0+b3duZXIpKQo+ICsJCXJldHVybiBOVUxMOwo+ICsKPiArCWtyZWZfZ2V0KCZyZWNvcmQt PmtyZWYpOwoKWW91ICJwcm90ZWN0IiBmcm9tIGEgbW9kdWxlIGJlaW5nIHJlbW92ZWQsIGJ1dCBu b3QgZnJvbSBzb21lb25lIGVsc2UKcmVsZWFzaW5nIHRoZSBrcmVmIGF0IHRoZSBzYW1lIHRpbWUu ICBXaGVyZSBpcyB0aGUgbG9jayB0aGF0IHByZXZlbnRzCnRoaXMgZnJvbSBoYXBwZW5pbmc/CgpB bmQgZG8gd2UgcmVhbGx5IGNhcmUgYWJvdXQgbW9kdWxlIHJlZmVyZW5jZSBjb3VudHMgaGVyZT8K Cj4gKwo+ICsJcmV0dXJuIHJlY29yZDsKPiArfQo+ICsKPiArLyoqCj4gKyAqIHJlZ2lzdHJ5X3Jl Y29yZF91bnJlZiAtIGRyb3AgYSByZWZlcmVuY2UgdG8gYSByZWdpc3RyeSByZWNvcmQKPiArICog QHJlY29yZDogcmVjb3JkIHRvIHVucmVmZXJlbmNlCj4gKyAqCj4gKyAqIERlY3JlYXNlcyB0aGUg cmVmZXJlbmNlIGNvdW50IG9uIHRoZSByZWNvcmQuIFdoZW4gdGhlIHJlZmVyZW5jZSBjb3VudAo+ ICsgKiByZWFjaGVzIHplcm8gdGhlIHJlY29yZCB3aWxsIGJlIGRlc3Ryb3llZC4KPiArICovCj4g K3ZvaWQgcmVnaXN0cnlfcmVjb3JkX3VucmVmKHN0cnVjdCByZWdpc3RyeV9yZWNvcmQgKnJlY29y ZCkKPiArewo+ICsJaWYgKHJlY29yZCkgewo+ICsJCS8qCj4gKwkJICogS2VlcCBhIGNvcHkgb2Yg dGhlIG1vZHVsZSBvd25lciBzaW5jZSB0aGUgcmVjb3JkIG1heQo+ICsJCSAqIGRpc2FwcGVhciBk dXJpbmcgdGhlIGtyZWZfcHV0KCkuCj4gKwkJICovCj4gKwkJc3RydWN0IG1vZHVsZSAqb3duZXIg PSByZWNvcmQtPm93bmVyOwo+ICsKPiArCQlrcmVmX3B1dCgmcmVjb3JkLT5rcmVmLCByZWdpc3Ry eV9yZWNvcmRfcmVsZWFzZSk7Cj4gKwkJbW9kdWxlX3B1dChvd25lcik7Cj4gKwl9Cj4gK30KPiAr Cj4gKy8qKgo+ICsgKiByZWdpc3RyeV9hZGQgLSBhZGQgYSByZWNvcmQgdG8gYSByZWdpc3RyeQo+ ICsgKiBAcmVnaXN0cnk6IHJlZ2lzdHJ5IHRvIGFkZCB0aGUgcmVjb3JkIHRvCj4gKyAqIEByZWNv cmQ6IHJlY29yZCB0byBhZGQKPiArICoKPiArICogVHJpZXMgdG8gaW5jcmVhc2UgdGhlIHJlZmVy ZW5jZSBjb3VudCBvZiB0aGUgbW9kdWxlIG93bmluZyB0aGUgcmVnaXN0cnkuIElmCj4gKyAqIHN1 Y2Nlc3NmdWwgYWRkcyB0aGUgbmV3IHJlY29yZCB0byB0aGUgcmVnaXN0cnkuCj4gKyAqCj4gKyAq IFJldHVybjogMCBvbiBzdWNjZXNzIG9yIGEgbmVnYXRpdmUgZXJyb3IgY29kZSBvbiBmYWlsdXJl Lgo+ICsgKi8KPiAraW50IHJlZ2lzdHJ5X2FkZChzdHJ1Y3QgcmVnaXN0cnkgKnJlZ2lzdHJ5LCBz dHJ1Y3QgcmVnaXN0cnlfcmVjb3JkICpyZWNvcmQpCj4gK3sKPiArCWlmICghdHJ5X21vZHVsZV9n ZXQocmVnaXN0cnktPm93bmVyKSkKPiArCQlyZXR1cm4gLUVOT0RFVjsKPiArCj4gKwltdXRleF9s b2NrKCZyZWdpc3RyeS0+bG9jayk7Cj4gKwlsaXN0X2FkZF90YWlsKCZyZWNvcmQtPmxpc3QsICZy ZWdpc3RyeS0+bGlzdCk7Cj4gKwltdXRleF91bmxvY2soJnJlZ2lzdHJ5LT5sb2NrKTsKCk5vIGlu Y3JlbWVudGluZyBvZiB0aGUgcmVmZXJlbmNlIG9mIHRoZSByZWNvcmQgYXQgYWxsPwoKWW91IHNl ZW0gdG8gYmUgdXNpbmcgMiByZWZlcmVuY2UgY291bnRzIGZvciB0aGUgcmVjb3JkIC8gcmVnaXN0 cnksIGEKbW9kdWxlIGNvdW50LCBhbmQgYSBrcmVmIGNvdW50LCB3aGljaCBjYW4gY2F1c2UgY29u ZnVzaW9uLi4uCgp0aGFua3MsCgpncmVnIGstaApfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0 cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753056AbaKDQj4 (ORCPT ); Tue, 4 Nov 2014 11:39:56 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:45600 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751104AbaKDQjz (ORCPT ); Tue, 4 Nov 2014 11:39:55 -0500 Date: Tue, 4 Nov 2014 08:38:45 -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: <20141104163845.GA369@kroah.com> References: <1415118568-18771-1-git-send-email-thierry.reding@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1415118568-18771-1-git-send-email-thierry.reding@gmail.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 Tue, Nov 04, 2014 at 05:29:27PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Add a generic implementation of an object registry. This targets drivers > and subsystems that provide auxiliary objects that other drivers need to > look up. The goal is to put the difficult parts (keep object references, > module usage count, ...) into core code so that individual subsystems do > not have to deal with them. > > The intention is for subsystems to instantiate a struct registry and use > a struct registry_record embedded into a subsystem-specific structure to > provide a subsystem-specific API around that. > > Signed-off-by: Thierry Reding > --- > drivers/base/Makefile | 2 +- > drivers/base/registry.c | 147 +++++++++++++++++++++++++++++++++++++++++++++++ > include/linux/registry.h | 62 ++++++++++++++++++++ > 3 files changed, 210 insertions(+), 1 deletion(-) > create mode 100644 drivers/base/registry.c > create mode 100644 include/linux/registry.h > > diff --git a/drivers/base/Makefile b/drivers/base/Makefile > index 53c3fe1aeb29..250262d1af2c 100644 > --- a/drivers/base/Makefile > +++ b/drivers/base/Makefile > @@ -4,7 +4,7 @@ obj-y := component.o core.o bus.o dd.o syscore.o \ > driver.o class.o platform.o \ > cpu.o firmware.o init.o map.o devres.o \ > attribute_container.o transport_class.o \ > - topology.o container.o property.o > + topology.o container.o property.o registry.o > obj-$(CONFIG_DEVTMPFS) += devtmpfs.o > obj-$(CONFIG_DMA_CMA) += dma-contiguous.o > obj-y += power/ > diff --git a/drivers/base/registry.c b/drivers/base/registry.c > new file mode 100644 > index 000000000000..9f510f6237b7 > --- /dev/null > +++ b/drivers/base/registry.c > @@ -0,0 +1,147 @@ > +/* > + * Copyright (C) 2014, NVIDIA Corporation. All rights reserved. > + * > + * This file is released under the GPL v2. > + */ > + > +#include > +#include > +#include > + > +static inline struct registry_record *to_registry_record(struct kref *kref) > +{ > + return container_of(kref, struct registry_record, kref); > +} > + > +static void registry_record_release(struct kref *kref) > +{ > + struct registry_record *record = to_registry_record(kref); > + > + record->release(record); > +} > + > +/** > + * registry_record_init - initialize a registry record > + * @record: record to initialize > + * > + * Sets up internal fields of the registry record so that it can subsequently > + * be added to a registry. > + */ > +void registry_record_init(struct registry_record *record) > +{ > + INIT_LIST_HEAD(&record->list); > + kref_init(&record->kref); > +} > + > +/** > + * registry_record_ref - reference on the registry record > + * @record: record to reference > + * > + * Increases the reference count on the record and returns a pointer to it. > + * > + * Return: A pointer to the record on success or NULL on failure. > + */ > +struct registry_record *registry_record_ref(struct registry_record *record) > +{ > + if (!record) > + return NULL; > + > + /* > + * Refuse to give out any more references if the module owning the > + * record is being removed. > + */ > + if (!try_module_get(record->owner)) > + return NULL; > + > + kref_get(&record->kref); You "protect" from a module being removed, but not from someone else releasing the kref at the same time. Where is the lock that prevents this from happening? And do we really care about module reference counts here? > + > + return record; > +} > + > +/** > + * registry_record_unref - drop a reference to a registry record > + * @record: record to unreference > + * > + * Decreases the reference count on the record. When the reference count > + * reaches zero the record will be destroyed. > + */ > +void registry_record_unref(struct registry_record *record) > +{ > + if (record) { > + /* > + * Keep a copy of the module owner since the record may > + * disappear during the kref_put(). > + */ > + struct module *owner = record->owner; > + > + kref_put(&record->kref, registry_record_release); > + module_put(owner); > + } > +} > + > +/** > + * registry_add - add a record to a registry > + * @registry: registry to add the record to > + * @record: record to add > + * > + * Tries to increase the reference count of the module owning the registry. If > + * successful adds the new record to the registry. > + * > + * Return: 0 on success or a negative error code on failure. > + */ > +int registry_add(struct registry *registry, struct registry_record *record) > +{ > + if (!try_module_get(registry->owner)) > + return -ENODEV; > + > + mutex_lock(®istry->lock); > + list_add_tail(&record->list, ®istry->list); > + mutex_unlock(®istry->lock); No incrementing of the reference of the record at all? You seem to be using 2 reference counts for the record / registry, a module count, and a kref count, which can cause confusion... thanks, greg k-h