All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>, Greg K-H <greg@kroah.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	dmitry.torokhov@gmail.com
Subject: Re: [PATCH RFD] alternative kobject release wait mechanism
Date: Wed, 18 Apr 2007 17:46:09 +0900	[thread overview]
Message-ID: <4625DAD1.2070000@gmail.com> (raw)
In-Reply-To: <20070418101117.73edb302@gondolin.boeblingen.de.ibm.com>

Cornelia Huck wrote:
> On Wed, 18 Apr 2007 03:49:01 +0900,
> Tejun Heo <htejun@gmail.com> wrote:
> 
>> Oh, one more thing, with proper code audit, we can just make
>> device_unregister() do the waiting instead of adding separate
>> device_unregister_wait().  I think that will be a good step toward
>> immediate-detach driver model.
> 
> Do we really want that? If the release function doesn't sit in the
> module, or if the device_unregister() is done for other reasons in a
> non-module, we don't care about lingering references. There's no need
> to wait (and possibly lock up) there.

It's debatable but I think things will be safer this way.  If we wait by
default, we are forced to check that all references are dropped and will
have a stack dump indicating which object is causing problem when
something goes wrong, which is better than silent object leaking and/or
jumping to non-existent address way later.

I personally think all driver interface should be made this way such
that completion of unregister function guarantees no further access to
the object or module.  IMHO, it's more intuitive and easier to force
correctness.

I'm not sure about kobject_put() but device_unregister() waiting for
release doesn't sound bad to me.

-- 
tejun

  reply	other threads:[~2007-04-18  8:46 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-16 17:36 [Patch -mm 0/3] RFC: module unloading vs. release function Cornelia Huck
2007-04-16 18:30 ` Dmitry Torokhov
2007-04-16 18:47   ` Greg KH
2007-04-16 19:03     ` Dmitry Torokhov
2007-04-16 19:11       ` Greg KH
2007-04-16 20:20         ` Dmitry Torokhov
2007-04-16 19:38   ` Alan Stern
2007-04-16 19:47     ` Dmitry Torokhov
2007-04-16 19:52       ` Greg KH
2007-04-16 20:18         ` Dmitry Torokhov
2007-04-16 21:02           ` Alan Stern
2007-04-17  7:49             ` Cornelia Huck
2007-04-16 20:44     ` Alexey Dobriyan
2007-04-17  2:55       ` Rusty Russell
2007-04-17  7:36     ` Cornelia Huck
2007-04-16 18:53 ` Greg KH
2007-04-17 18:41 ` [PATCH RFD] alternative kobject release wait mechanism Tejun Heo
2007-04-17 18:49   ` Tejun Heo
2007-04-18  8:11     ` Cornelia Huck
2007-04-18  8:46       ` Tejun Heo [this message]
2007-04-18  9:35         ` Cornelia Huck
2007-04-18  9:55           ` Tejun Heo
2007-04-18  8:07   ` Cornelia Huck
2007-04-18  8:36     ` Tejun Heo
2007-04-18 14:53   ` Alan Stern
2007-04-18 15:26     ` Cornelia Huck
2007-04-18 15:34     ` Tejun Heo
2007-04-18 15:45       ` Tejun Heo
2007-04-18 19:07         ` Alan Stern
2007-04-20  5:27           ` Tejun Heo
2007-04-20  9:11             ` Cornelia Huck
2007-04-20 15:01             ` Alan Stern
2007-04-20 15:57               ` Dmitry Torokhov
2007-04-21 15:19                 ` Alan Stern
2007-04-20 15:40             ` Alan Stern
2007-04-21  0:03               ` Greg KH
2007-04-21 21:36                 ` Alan Stern
2007-04-22 17:40                   ` Greg KH
2007-04-23  7:08                     ` Cornelia Huck
2007-04-23 19:47                       ` Alan Stern
2007-04-24 19:38                     ` Alan Stern
2007-04-25  9:00                       ` Cornelia Huck
2007-04-25 20:13                         ` Alan Stern
2007-04-26  8:21                           ` Cornelia Huck
2007-04-26 14:58                             ` Alan Stern
2007-04-26 15:12                               ` Cornelia Huck
2007-04-18 16:11       ` Alan Stern
2007-04-18 16:38         ` Tejun Heo
2007-04-18 16:41       ` Dmitry Torokhov
2007-04-19 12:51         ` Cornelia Huck
2007-04-19 13:13           ` Dmitry Torokhov
2007-04-19 13:48             ` Cornelia Huck
2007-04-19 14:21               ` Dmitry Torokhov
2007-04-20  5:59                 ` Tejun Heo
2007-04-20 16:35                   ` Dmitry Torokhov
2007-04-20 16:52                     ` Tejun Heo
2007-04-20 17:59                       ` Dmitry Torokhov
2007-04-23  6:40                         ` Tejun Heo
2007-04-23  6:53                           ` Greg KH
2007-04-19 17:19         ` Alan Stern
2007-04-19 18:39           ` Dmitry Torokhov
2007-04-19 22:37             ` Alan Stern
2007-04-20 16:35               ` Dmitry Torokhov
2007-04-21 15:30                 ` Alan Stern
2007-04-18 15:06   ` Cornelia Huck
2007-04-18 16:06     ` Tejun Heo
2007-04-19 13:29       ` Cornelia Huck
2007-04-19 14:20         ` Alan Stern
2007-04-19 14:49           ` Cornelia Huck
2007-04-20  9:04             ` Cornelia Huck

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=4625DAD1.2070000@gmail.com \
    --to=htejun@gmail.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --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 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.