From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Petr Mladek <pmladek@suse.cz>
Cc: Seth Jennings <sjenning@redhat.com>,
Jiri Kosina <jkosina@suse.cz>,
Rusty Russell <rusty@rustcorp.com.au>,
Miroslav Benes <mbenes@suse.cz>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
mingo@kernel.org, mathieu.desnoyers@efficios.com,
oleg@redhat.com, paulmck@linux.vnet.ibm.com,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
andi@firstfloor.org, rostedt@goodmis.org, tglx@linutronix.de
Subject: Re: [PATCH v3] livepatch/module: Correctly handle coming and going modules
Date: Tue, 10 Mar 2015 09:22:04 -0500 [thread overview]
Message-ID: <20150310142204.GK10815@treble.redhat.com> (raw)
In-Reply-To: <20150310120103.GC1813@dhcp128.suse.cz>
On Tue, Mar 10, 2015 at 01:01:07PM +0100, Petr Mladek wrote:
> On Mon 2015-03-09 09:40:55, Josh Poimboeuf wrote:
> > On Mon, Mar 09, 2015 at 02:25:28PM +0100, Petr Mladek wrote:
> > > +
> > > mutex_unlock(&module_mutex);
> > > }
> > >
> > > @@ -736,6 +748,7 @@ static int klp_init_object(struct klp_patch *patch, struct klp_object *obj)
> > > return -EINVAL;
> > >
> > > obj->state = KLP_DISABLED;
> > > + obj->mod = NULL;
> > >
> > > klp_find_object_module(obj);
> > >
> > > @@ -926,6 +939,15 @@ static int klp_module_notify(struct notifier_block *nb, unsigned long action,
> > >
> > > mutex_lock(&klp_mutex);
> > >
> > > + /*
> > > + * Each module has to know that the notifier has been called.
> > > + * We never know what module will get patched by a new patch.
> > > + */
> > > + if (action == MODULE_STATE_COMING)
> > > + mod->klp_alive = true;
> > > + else /* MODULE_STATE_GOING */
> > > + mod->klp_alive = false;
> > > +
> >
> > Any reason why this needs to be protected by the mutex?
>
> We need to synchronize it with the check in
> klp_find_object_module(). Otherwise, for example, the check might read
> "true" and add/enable new patch but this notify handler will be
> blocked until the patch is added => it will mess the order of
> patches.
>
> It might be more clean to take module_mutex here but the value is
> needed only by livepatching, so klp_mutex seems to be enough.
Ah, right. Looks good to me.
> > > list_for_each_entry(patch, &klp_patches, list) {
> > > for (obj = patch->objs; obj->funcs; obj++) {
> > > if (!klp_is_module(obj) || strcmp(obj->name, mod->name))
> > > diff --git a/kernel/module.c b/kernel/module.c
> > > index d856e96a3cce..b3ffc231ce0d 100644
> > > --- a/kernel/module.c
> > > +++ b/kernel/module.c
> > > @@ -3271,6 +3271,10 @@ static int load_module(struct load_info *info, const char __user *uargs,
> > > }
> > > #endif
> > >
> > > +#ifdef CONFIG_LIVEPATCH
> > > + mod->klp_alive = false;
> > > +#endif
> > > +
> >
> > I don't think you need this initialization. It looks like the module
> > struct is embedded in the mod->module_core region which is initialized
> > to zero in move_module().
>
> I have looked at this before but I was not able to find a code
> zeroing struct module. If I get it correctly, mod->module_core
> is a location where symbol table sections are copied or so.
Yeah, it's far from obvious. AFAICT, it's cleared by the
"memset(ptr, 0, mod->core_size)" line.
--
Josh
next prev parent reply other threads:[~2015-03-10 14:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-09 13:25 [PATCH v3] livepatch/module: Correctly handle coming and going modules Petr Mladek
2015-03-09 14:40 ` Josh Poimboeuf
2015-03-10 12:01 ` Petr Mladek
2015-03-10 14:22 ` Josh Poimboeuf [this message]
2015-03-10 14:36 ` Petr Mladek
2015-03-10 14:47 ` Josh Poimboeuf
2015-03-10 16:58 ` Petr Mladek
2015-03-10 17:07 ` Petr Mladek
2015-03-10 17:30 ` Josh Poimboeuf
2015-03-12 0:33 ` Rusty Russell
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=20150310142204.GK10815@treble.redhat.com \
--to=jpoimboe@redhat.com \
--cc=andi@firstfloor.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mbenes@suse.cz \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pmladek@suse.cz \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=sjenning@redhat.com \
--cc=tglx@linutronix.de \
/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.