mirror of https://lore.kernel.org/lkml/
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome