public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	David Herrmann <dh.herrmann@gmail.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 1/2] core: Add generic object registry implementation
Date: Wed, 5 Nov 2014 10:13:53 +0100	[thread overview]
Message-ID: <20141105091351.GA12033@ulmo> (raw)
In-Reply-To: <20141104163845.GA369@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 2860 bytes --]

On Tue, Nov 04, 2014 at 08:38:45AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Nov 04, 2014 at 05:29:27PM +0100, Thierry Reding wrote:
[...]
> > diff --git a/drivers/base/registry.c b/drivers/base/registry.c
[...]
> > +/**
> > + * 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?

You're right, we need a record lock to serialize ref/unref.

> And do we really care about module reference counts here?

We need this so that the code of the .release() callback stays in
memory as long as there are any references.

Also we need the module reference count for registries because they
would typically be statically allocated and go away along with a module
when it is unloaded.

> > +/**
> > + * 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(&registry->lock);
> > +	list_add_tail(&record->list, &registry->list);
> > +	mutex_unlock(&registry->lock);
> 
> No incrementing of the reference of the record at all?

I'm not sure if we really need one. Drivers will have to remove the
record from the registry before dropping their reference. I guess we
could throw in another kref_get() here (and a kref_put() in
registry_remove()) for good measure to prevent breakage with buggy
drivers.

> You seem to be using 2 reference counts for the record / registry, a
> module count, and a kref count, which can cause confusion...

There is one reference count (kref actually) per registry record and one
module count for the record owner and the registry owner.

Can you elaborate what you think is confusing? Perhaps I can add more
kerneldoc to clarify.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-11-05  9:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-04 16:29 [RFC 1/2] core: Add generic object registry implementation Thierry Reding
2014-11-04 16:29 ` [RFC 2/2] drm/panel: Use generic object registry Thierry Reding
2014-11-04 16:38 ` [RFC 1/2] core: Add generic object registry implementation Greg Kroah-Hartman
2014-11-05  9:13   ` Thierry Reding [this message]
2014-11-06  2:18     ` Greg Kroah-Hartman
2014-11-06 10:25       ` Thierry Reding
2014-11-06 16:13         ` Thierry Reding
2014-11-07 16:31           ` Greg Kroah-Hartman
2014-11-05 12:36 ` Andrzej Hajda
2014-11-05 14:04   ` Thierry Reding
2014-11-05 16:00     ` Andrzej Hajda
2014-11-06  9:48       ` Thierry Reding
2014-11-07  9:10         ` Andrzej Hajda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141105091351.GA12033@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dh.herrmann@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox