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:36:21 +0900 [thread overview]
Message-ID: <4625D885.7020308@gmail.com> (raw)
In-Reply-To: <20070418100709.3c710e00@gondolin.boeblingen.de.ibm.com>
Cornelia Huck wrote:
> On Wed, 18 Apr 2007 03:41:10 +0900,
> Tejun Heo <htejun@gmail.com> wrote:
>
>> Hello, all.
>>
>> Agreed with the problem but I'm not very enthusiastic for adding
>> kobj->owner. How about the following? exit() routines will have to
>> do device_unregister_wait() instead of device_unregister(). On return
>> from it, it's guaranteed that all references to it are dropped and
>> ->release is finished.
>
> Sounds interesting. Kind of like the completion approach, but with the
> dangerous bits outside the module.
>
>> The caller is responsible for avoiding
>> deadlock, of course.
>
> I think that wording is a bit too strong. Of course, if the device is
> unregistered in the exit routine, the module must make sure it gave up
> all references it itself obtained. However, it doesn't have any control
> about who obtained a reference during the object's lifetime. If an
> outsider holds on to a reference, we'll lock up until this reference
> has been given up (but I guess this is what we want).
Right, the better wording would be "the caller is responsible for not
causing deadlocks by dropping all references it owns on entry".
>> +void kobject_put_wait(struct kobject * kobj)
>> +{
>> + struct kobj_wait kwait;
>> + unsigned long flags;
>> +
>> + if (!kobj)
>> + return;
>> +
>> + BUG_ON(!list_empty(&kobj->entry));
>> +
>> + init_completion(&kwait.cmpl);
>> + kwait.kobj = kobj;
>> +
>> + spin_lock_irqsave(&kobj_wait_lock, flags);
>> + list_add(&kwait.list, &kobj_wait_list);
>> + spin_unlock_irqrestore(&kobj_wait_lock, flags);
>> +
>> + kobject_put(kobj);
>> +
>> + if (!wait_for_completion_timeout(&kwait.cmpl, 30 * HZ)) {
>> + printk(KERN_WARNING "kobject_put_wait: kobject %p is still "
>> + "alive after 30s, possible reference count bug\n", kobj);
>> + dump_stack();
>> + wait_for_completion(&kwait.cmpl);
>> + }
>> +}
>>
>
> Couldn't this waiting be made simpler?
> - add completion to kobject in kobject_unregister_wait()
> - call kobject_put(), then wait_for_completion()
> - in kobject_cleanup(), save completion from kobject, call release
> function, then complete() on saved completion
I was trying to avoid adding a completion to all kobjects.
Thanks.
--
tejun
next prev parent reply other threads:[~2007-04-18 8:36 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
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 [this message]
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=4625D885.7020308@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome