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: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

  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 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.