From: Jeff Mahoney <jeffm@suse.com>
To: Greg KH <gregkh@linux.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH 1/2] kobject: introduce kobj_completion
Date: Tue, 10 Sep 2013 14:33:00 -0400 [thread overview]
Message-ID: <522F65DC.1010303@suse.com> (raw)
In-Reply-To: <20130910180627.GA4274@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 3892 bytes --]
On 9/10/13 2:06 PM, Greg KH wrote:
> On Tue, Sep 10, 2013 at 01:44:10PM -0400, Jeff Mahoney wrote:
>> ext4 exports per-filesystem information via sysfs. The lifetime rules
>> have historically been painful for this but the solution has been to pair
>> the kobject with a completion and call complete in the kobject's
>> release function.
>>
>> Since this is a pattern I've used in btrfs as well, it makes sense to
>> turn the pairing into a convenience structure with a standard API.
>>
>> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
>> ---
>> include/linux/kobj_completion.h | 18 +++++++++++++++
>> lib/kobject.c | 47 ++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 65 insertions(+)
>>
>> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
>> +++ b/include/linux/kobj_completion.h 2013-09-10 12:58:03.530554144 -0400
>> @@ -0,0 +1,18 @@
>> +#ifndef _KOBJ_COMPLETION_H_
>> +#define _KOBJ_COMPLETION_H_
>> +
>> +#include <linux/kobject.h>
>> +#include <linux/completion.h>
>> +
>> +struct kobj_completion {
>> + struct kobject kc_kobj;
>> + struct completion kc_unregister;
>> +};
>> +
>> +#define kobj_to_kobj_completion(kobj) \
>> + container_of(kobj, struct kobj_completion, kc_kobj)
>> +
>> +void kobj_completion_init(struct kobj_completion *kc, struct kobj_type *ktype);
>> +void kobj_completion_release(struct kobject *kobj);
>> +void kobj_completion_del_and_wait(struct kobj_completion *kc);
>> +#endif /* _KOBJ_COMPLETION_H_ */
>> --- a/lib/kobject.c 2013-09-10 12:57:54.198666613 -0400
>> +++ b/lib/kobject.c 2013-09-10 13:16:31.750607946 -0400
>> @@ -13,6 +13,7 @@
>> */
>>
>> #include <linux/kobject.h>
>> +#include <linux/kobj_completion.h>
>> #include <linux/string.h>
>> #include <linux/export.h>
>> #include <linux/stat.h>
>> @@ -711,6 +712,52 @@ const struct sysfs_ops kobj_sysfs_ops =
>> };
>>
>> /**
>> + * kobj_completion_init - initialize a kobj_completion object.
>> + * @kc: kobj_completion
>> + * @ktype: type of kobject to initialize
>> + *
>> + * kobj_completion structures can be embedded within structures with different
>> + * lifetime rules. During the release of the enclosing object, we can
>> + * wait on the release of the kobject so that we don't free it while it's
>> + * still busy.
>> + */
>> +void kobj_completion_init(struct kobj_completion *kc, struct kobj_type *ktype)
>> +{
>> + init_completion(&kc->kc_unregister);
>> + kobject_init(&kc->kc_kobj, ktype);
>> +}
>> +EXPORT_SYMBOL_GPL(kobj_completion_init);
>> +
>> +/**
>> + * kobj_completion_release - release a kobj_completion object
>> + * @kobj: kobject embedded in kobj_completion
>> + *
>> + * Used with kobject_release to notify waiters that the kobject has been
>> + * released.
>> + */
>> +void kobj_completion_release(struct kobject *kobj)
>> +{
>> + struct kobj_completion *kc = kobj_to_kobj_completion(kobj);
>> + complete(&kc->kc_unregister);
>> +}
>> +EXPORT_SYMBOL_GPL(kobj_completion_release);
>> +
>> +/**
>> + * kobj_completion_del_and_wait - release the kobject and wait for it
>> + * @kc: kobj_completion object to release
>> + *
>> + * Delete the kobject from sysfs and drop the reference count. Then wait
>> + * until any outstanding references are also dropped.
>> + */
>> +void kobj_completion_del_and_wait(struct kobj_completion *kc)
>> +{
>> + kobject_del(&kc->kc_kobj);
>> + kobject_put(&kc->kc_kobj);
>
> Why the extra kobject_put() call? Who added this extra reference to the
> object?
There's an assumption that kobject_add will have been called on the
initialized kobject. If it hasn't been called, the object can just be
deleted without the completion. It makes the calling code easier to
read, so would it work for you if I documented that assumption in
_del_and_wait?
-Jeff
--
Jeff Mahoney
SUSE Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
next prev parent reply other threads:[~2013-09-10 18:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 17:44 [PATCH 1/2] kobject: introduce kobj_completion Jeff Mahoney
2013-09-10 18:06 ` Greg KH
2013-09-10 18:33 ` Jeff Mahoney [this message]
2013-09-10 18:44 ` Jeff Mahoney
2013-09-11 4:50 ` Greg KH
2013-09-11 16:53 ` Jeff Mahoney
2013-09-11 16:59 ` Greg KH
2013-09-10 18:49 ` Greg KH
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=522F65DC.1010303@suse.com \
--to=jeffm@suse.com \
--cc=gregkh@linux.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.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;
as well as URLs for NNTP newsgroup(s).