All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Zippel <zippel@linux-m68k.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: viro@parcelfarce.linux.theplanet.co.uk, torvalds@osdl.org,
	stern@rowland.harvard.edu, greg@kroah.com,
	linux-kernel@vger.kernel.org, mochel@digitalimplant.org
Subject: Re: PATCH: (as177)  Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core
Date: Tue, 27 Jan 2004 14:56:06 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.58.0401271142510.7855@serv> (raw)
In-Reply-To: <20040127175104.48bd8664.rusty@rustcorp.com.au>

Hi,

On Tue, 27 Jan 2004, Rusty Russell wrote:

> viro@parcelfarce.linux.theplanet.co.uk wrote:
>
> > Basically, "protect the module" is wrong - it should be "protect specific
> > object" and we need that anyway.
>
> Agreed.  You're oversimplifying a little, though.
>
> In this model, the object here is the function text.  So if you hand out
> a pointer to the function text, you need to hold a refcount.
>
> BUT since the module itself is the only one which can hand these out,
> and it unregisters everything it has registered, and all those references
> fall to zero, it's trivial to prove that there are no more references to
> the module functions.

There is a very simple rule: If two or more objects have the same
lifetime, they all only need to be protected once.
So if you have two static objects (e.g. a static structure with a
reference to a function), the module count is indeed enough to protect
both objects. The problem starts when you mix dynamic and static objects,
then the module count is not enough anymore and you have to use proper
refcounts, but the generic module code currently has no decent way to get
to that information, so we have to maintain the module count additionally
to the refcount. Now we only have to find a way to utilize the object
protection to also protect the module it refers to and you can get rid of
the module count.
Rusty, you need to get away from this idea, that every single function
pointer must be protected by itself, it can also be protected via another
object, the real problem is that the generic module code doesn't know
anything about this. Fixing this requires changing every single module,
but in the end it would be worth it, as it avoids the duplicated
protection and we had decent module unload semantics.

bye, Roman

  reply	other threads:[~2004-01-27 13:56 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-23 16:58 PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core Alan Stern
2004-01-23 17:42 ` Linus Torvalds
2004-01-23 18:03   ` Alan Stern
2004-01-23 18:10     ` viro
2004-01-23 18:18       ` Greg KH
2004-01-23 18:15     ` Linus Torvalds
2004-01-23 18:31       ` Greg KH
2004-01-23 18:11   ` Greg KH
2004-01-23 18:19     ` Linus Torvalds
2004-01-23 18:27       ` Greg KH
2004-01-25 17:32       ` Alan Stern
2004-01-25 19:02         ` Linus Torvalds
2004-01-25 20:21           ` viro
2004-01-27  6:51             ` Rusty Russell
2004-01-27 13:56               ` Roman Zippel [this message]
2004-01-27 23:29                 ` Rusty Russell
2004-01-28  2:36                   ` Roman Zippel
2004-01-28  3:54                     ` Rusty Russell
2004-01-25 23:12           ` Steve Youngs
2004-01-26  3:22             ` Adam Kropelin
2004-01-26  5:06               ` Steve Youngs
2004-01-26  5:21                 ` Valdis.Kletnieks
2004-01-26  5:55                   ` Steve Youngs
2004-01-26  6:25                     ` Valdis.Kletnieks
2004-01-26  8:48                     ` Helge Hafting
2004-01-26 15:50                 ` Adam Kropelin
2004-01-26 16:22           ` Roman Zippel
2004-01-27 19:32             ` Russell King
2004-01-27 20:28               ` Greg KH
2004-01-27 20:29             ` Greg KH
2004-01-28  2:03               ` Roman Zippel
2004-01-28  2:17                 ` viro
2004-01-28  2:53                   ` Roman Zippel
2004-01-27  6:41           ` Rusty Russell
2004-01-23 19:45     ` viro
2004-01-26  5:50     ` Rusty Russell
2004-01-26 15:51       ` Alan Stern
2004-01-27 22:55         ` Rusty Russell

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=Pine.LNX.4.58.0401271142510.7855@serv \
    --to=zippel@linux-m68k.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@digitalimplant.org \
    --cc=rusty@rustcorp.com.au \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@osdl.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.