From: Ming Lei <ming.lei@redhat.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Joe Lawrence <joe.lawrence@redhat.com>,
ming.lei@redhat.com
Subject: Re: [PATCH V4 1/3] livepatch: remove 'struct completion finish' from klp_patch
Date: Wed, 3 Nov 2021 08:51:32 +0800 [thread overview]
Message-ID: <YYHdFLwGry58Q16F@T590> (raw)
In-Reply-To: <YYFfmo5/Dds7bspY@alley>
On Tue, Nov 02, 2021 at 04:56:10PM +0100, Petr Mladek wrote:
> On Tue 2021-11-02 22:59:30, Ming Lei wrote:
> > The completion finish is just for waiting release of the klp_patch
> > object, then releases module refcnt. We can simply drop the module
> > refcnt in the kobject release handler of klp_patch.
> >
> > This way also helps to support allocating klp_patch from heap.
>
> IMHO, this is wrong assumption. kobject_put() might do everyting
> asynchronously, see:
>
> kobject_put()
> kobject_release()
> INIT_DELAYED_WORK(&kobj->release, kobject_delayed_cleanup);
> schedule_delayed_work(&kobj->release, delay);
>
> asynchronously:
>
> kobject_delayed_cleanup()
> kobject_cleanup()
> __kobject_del()
OK, this is one generic kobject release vs. module unloading issue to
solve, not unique for klp module, and there should be lots of drivers
suffering from it.
>
>
> > Signed-off-by: Ming Lei <ming.lei@redhat.com>
> > ---
> > include/linux/livepatch.h | 1 -
> > kernel/livepatch/core.c | 12 +++---------
> > 2 files changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> > index 2614247a9781..9712818997c5 100644
> > --- a/include/linux/livepatch.h
> > +++ b/include/linux/livepatch.h
> > @@ -170,7 +170,6 @@ struct klp_patch {
> > bool enabled;
> > bool forced;
> > struct work_struct free_work;
> > - struct completion finish;
> > };
> >
> > #define klp_for_each_object_static(patch, obj) \
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index 335d988bd811..b967b4b0071b 100644
> > --- a/kernel/livepatch/core.c
> > +++ b/kernel/livepatch/core.c
> > @@ -551,10 +551,10 @@ static int klp_add_nops(struct klp_patch *patch)
> >
> > static void klp_kobj_release_patch(struct kobject *kobj)
> > {
> > - struct klp_patch *patch;
> > + struct klp_patch *patch = container_of(kobj, struct klp_patch, kobj);
> >
> > - patch = container_of(kobj, struct klp_patch, kobj);
> > - complete(&patch->finish);
> > + if (!patch->forced)
> > + module_put(patch->mod);
> > }
> >
> > static struct kobj_type klp_ktype_patch = {
> > @@ -678,11 +678,6 @@ static void klp_free_patch_finish(struct klp_patch *patch)
> > * cannot get enabled again.
> > */
> > kobject_put(&patch->kobj);
> > - wait_for_completion(&patch->finish);
> > -
> > - /* Put the module after the last access to struct klp_patch. */
> > - if (!patch->forced)
> > - module_put(patch->mod);
>
> klp_free_patch_finish() does not longer wait until the release
> callbacks are called.
>
> klp_free_patch_finish() is called also in klp_enable_patch() error
> path.
>
> klp_enable_patch() is called in module_init(). For example, see
> samples/livepatch/livepatch-sample.c
>
> The module must not get removed until the release callbacks are called.
> Does the module loader check the module reference counter when
> module_init() fails?
Good catch, that is really one corner case, in which the kobject has to
be cleaned up before returning from mod->init(), cause there can't be
module unloading in case of mod->init() failure.
Yeah, it should be more related with async kobject_put().
Also looks it is reasonable to add check when cleaning module loading
failure.
thanks,
Ming
next prev parent reply other threads:[~2021-11-03 0:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-02 14:59 [PATCH V4 0/3] livepatch: cleanup kpl_patch kobject release Ming Lei
2021-11-02 14:59 ` [PATCH V4 1/3] livepatch: remove 'struct completion finish' from klp_patch Ming Lei
2021-11-02 15:56 ` Petr Mladek
2021-11-03 0:51 ` Ming Lei [this message]
2021-11-03 12:52 ` Petr Mladek
2021-11-05 12:04 ` Ming Lei
2021-11-10 13:57 ` Petr Mladek
2021-11-08 17:46 ` Miroslav Benes
2021-11-02 14:59 ` [PATCH V4 2/3] livepatch: free klp_patch object without holding klp_mutex Ming Lei
2021-11-02 14:59 ` [PATCH V4 3/3] livepatch: free klp_patch object synchronously Ming Lei
2021-11-03 13:55 ` Petr Mladek
2021-11-05 7:59 ` Ming Lei
2021-11-10 14:42 ` Petr Mladek
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=YYHdFLwGry58Q16F@T590 \
--to=ming.lei@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mcgrof@kernel.org \
--cc=pmladek@suse.com \
/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.