From: Nicolai Stange <nicstange@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Nicolai Stange <nicstange@gmail.com>,
"Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Mark Fasheh <mfasheh@suse.com>, Joel Becker <jlbec@evilplan.org>,
Andrew Morton <akpm@linux-foundation.org>,
Joe Perches <joe@perches.com>,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
ocfs2-devel@oss.oracle.com
Subject: [PATCH v2] kset- and class-registration cleanups
Date: Wed, 18 Nov 2015 17:43:28 +0100 [thread overview]
Message-ID: <87k2pfcl73.fsf_-_@gmail.com> (raw)
In-Reply-To: <20151117041213.GA10860@kroah.com> (Greg Kroah-Hartman's message of "Mon, 16 Nov 2015 20:12:13 -0800")
In order to have something to base further discussion on, here comes the
second version.
In addition to some changes to the inital patch (now [1/3]), two
additional ones have been introduced.
The three patches depend on one another in sequence.
For a detailed changelist, see the end of this mail.
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Tue, Nov 17, 2015 at 01:04:19AM +0100, Nicolai Stange wrote:
> Yes, but those calls all succeed, so this isn't a problem in the "real"
> world :)
I added a word about non-impact in the commit message of [1/3].
>> +static void glue_dirs_release_dummy(struct kobject *kobj)
>> +{
>> + /*
>> + * The glue_dirs kset member of struct subsys_private is never
>> + * registered and thus, never unregistered.
>> + * This release function is a dummy to make kset_init() happy.
>> + */
>> + pr_err(
>> + "class (%p): unexpected kset_put() on glue_dirs, something is broken.",
>> + container_of(kobj, struct subsys_private,
>> + glue_dirs.kobj)->class);
>> + dump_stack();
>
> How can this ever happen?
Not at all. I'm not sure I understand you correctly here.
Do you strictly want to abandon the dummy releaser, or more specifically,
the dummy kobj_type?
For the moment, I turned the pr_err()/dump_stack() into a WARN() for the
sake of better style.
>> if (error) {
>> - kfree(cp);
>> + /*
>> + * class->release() would be called by cp->subsys'
>> + * release function. Prevent this from happening in
>> + * the error case by zeroing cp->class out.
>> + */
>> + cp->class = NULL;
>> + cls->p = NULL;
>> + kset_put(&cp->subsys);
>
> That seems pretty messy, why can't we allow the release to be called? I
> don't think this is really correct :(
At the moment, it is necessary. I've added [3/3] for the case that you
want cls->class_release() to get called from __class_register() on error.
In [3/3] you will also find the (few) callers expecting the behaviour as
it currently is.
Detailed changes from initial version to v2:
[1/3] lib/kobject: fix memory leak in error path of kset_create_and_add()
This one is the original patch with a few changes:
- added a word of non-impact to commit message
- use WARN() instead of open coded pr_error()/dump_stack() pair in
struct class' glue_dirs' dummy class releaser.
- follow my own advice in the docstring of kset_register() and
use kset_put() instead of kset_unregister() on error of
kset_register() in ext4's ext4_init_sysfs() and ocfs2's mlog_sys_init().
[2/3] drivers/base/class: __class_register(): make error behaviour consistent
This one is new and quite unrelated to the original patch.
Following the sidenote made in my last mail, it makes __class_register()
properly clean up after itself on error.
[3/3] drivers/base/class: __class_register(): invoke class' releaser on failure
This one is new.
It addresses Greg K-H's comment on the initial version about the messiness
of avoiding to call class->class_release() from __class_register() on
error. Given the fact that I had to introduce an explicit
cls->class_release() in the early part when there is no kset object
available yet, I'm by no means sure that it is much less messy now and
that this patch is worth the trouble.
-> It is up to you to judge.
As there are enough people bothered already, I did not CC the people
suggested for this one by get_maintainer.pl: all of them are maintainers
of external subsystems and probably not particularly interested in
__class_register() and friends. I will do this as soon as
a decision for this patch has been made, perhaps in a separate thread.
next prev parent reply other threads:[~2015-11-18 16:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-17 0:04 [PATCH] lib/kobject: fix memory leak in error path of kset_create_and_add() Nicolai Stange
2015-11-17 4:12 ` Greg Kroah-Hartman
2015-11-17 8:09 ` Nicolai Stange
2015-11-17 11:29 ` Nicolai Stange
2015-11-18 16:43 ` Nicolai Stange [this message]
2015-11-18 16:46 ` [PATCH v2 1/3] " Nicolai Stange
2015-11-18 16:48 ` [PATCH v2 2/3] drivers/base/class: __class_register(): make error behaviour consistent Nicolai Stange
2015-11-18 16:50 ` [PATCH v2 3/3] drivers/base/class: __class_register(): invoke class' releaser on failure Nicolai Stange
2016-02-23 14:58 ` [PATCH v2] kset- and class-registration cleanups Nicolai Stange
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=87k2pfcl73.fsf_-_@gmail.com \
--to=nicstange@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jlbec@evilplan.org \
--cc=joe@perches.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfasheh@suse.com \
--cc=ocfs2-devel@oss.oracle.com \
--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