mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Tejun Heo <htejun@gmail.com>,
	Markus Rechberger <markus.rechberger@amd.com>,
	USB development list <linux-usb-devel@lists.sourceforge.net>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: How should an exit routine wait for release() callbacks?
Date: Mon, 16 Apr 2007 10:53:16 +0200	[thread overview]
Message-ID: <20070416105316.0b91c2fd@gondolin.boeblingen.de.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0704131049380.3407-100000@iolanthe.rowland.org>

On Fri, 13 Apr 2007 11:24:58 -0400 (EDT),
Alan Stern <stern@rowland.harvard.edu> wrote:

> I have to admit, this is a puzzler.  I'm beginning to think there should 
> be two types of module references: Those which (like module dependency) 
> will prevent rmmod from running, and those which (like the one here) would 
> automatically be dropped by deregistration.  Then every kobject could have 
> an owner and could hold a reference of the second type to its owner until 
> its release routine returns.

This sounds like the most promising idea yet.

We could make kobject_add() bump up this second-type refcount (since
from now on it may be looked up). kobject_get()/kobject_put() wouldn't
need to grab an extra reference (we already have refcounting for this
object in place). kobject_cleanup() could do something like:

struct module * kobject_owner = kobj->owner;
...
call_release();
put_second_module_refcount(kobject_owner);

combined with the module unloading code waiting after calling the exit
function until the second type refcount dropped to 0. This would make
sure that the module is not deleted until the last release function has
been called.

The module would stay in memory (not be unloaded) until the last
kobject created by the module is deleted, but I think that is just what
we want. At least this doesn't mean that the module blocks its own
unloading.

  reply	other threads:[~2007-04-16  8:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-12 21:23 Alan Stern
2007-04-13  9:03 ` Cornelia Huck
2007-04-13 11:42   ` Markus Rechberger
2007-04-13 13:24     ` Cornelia Huck
2007-04-13 14:15       ` Markus Rechberger
2007-04-13 14:27         ` Cornelia Huck
2007-04-13 15:24           ` Alan Stern
2007-04-16  8:53             ` Cornelia Huck [this message]
2007-04-16 14:43               ` Alan Stern
2007-04-16 14:51                 ` [linux-usb-devel] " Robert Marquardt
2007-04-16 15:05                 ` Cornelia Huck
2007-04-16 22:12             ` [linux-usb-devel] " Greg KH
2007-04-17  7:26               ` Cornelia Huck
2007-04-17 15:59               ` Alan Stern

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=20070416105316.0b91c2fd@gondolin.boeblingen.de.ibm.com \
    --to=cornelia.huck@de.ibm.com \
    --cc=htejun@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=markus.rechberger@amd.com \
    --cc=stern@rowland.harvard.edu \
    /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

Powered by JetHome