From: Chris J Arges <chris.j.arges@canonical.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Jiri Kosina <jikos@kernel.org>,
jeyu@redhat.com, jpoimboe@redhat.com,
eugene.shatokhin@rosalab.ru, live-patching@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
pmladek@suse.cz
Subject: Re: Bug with paravirt ops and livepatches
Date: Fri, 1 Apr 2016 11:01:14 -0500 [thread overview]
Message-ID: <20160401160113.GA7837@canonical.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1604011745370.27264@pobox.suse.cz>
On Fri, Apr 01, 2016 at 05:46:52PM +0200, Miroslav Benes wrote:
> On Fri, 1 Apr 2016, Jiri Kosina wrote:
>
> > On Tue, 29 Mar 2016, Jiri Kosina wrote:
> >
> > > Agreed; I think we should be safe applying all the alternatives (with
> > > paravirt being really just a special case of those) to the coming module
> > > at the very last phase; they really are required only during runtime,
> > > but nothing else should be depending on them. Right? If anyone is able
> > > to come up with and counter-example, please speak up :)
> >
> > So I have quickly gone through all the architectures that actually do
> > overload __weak module_finalize() by their own implementation, and except
> > for applying self-modifying code changes and registering unwind tables,
> > there doesn't seem to be any relevant heavy-lifting, that'd need to be
> > done before relocations have been written.
> >
> > Is the (completely untested) sort-of-a-patch below a complete rubbish
> > (on top of current livepatching.git's for-next)?
> >
> >
> >
> >
> > diff --git a/kernel/module.c b/kernel/module.c
> > index 5f71aa6..c003648 100644
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -3211,7 +3211,7 @@ int __weak module_finalize(const Elf_Ehdr *hdr,
> > return 0;
> > }
> >
> > -static int post_relocation(struct module *mod, const struct load_info *info)
> > +static void post_relocation(struct module *mod, const struct load_info *info)
> > {
> > /* Sort exception table now relocations are done. */
> > sort_extable(mod->extable, mod->extable + mod->num_exentries);
> > @@ -3222,9 +3222,6 @@ static int post_relocation(struct module *mod, const struct load_info *info)
> >
> > /* Setup kallsyms-specific fields. */
> > add_kallsyms(mod, info);
> > -
> > - /* Arch-specific module finalizing. */
> > - return module_finalize(info->hdr, info->sechdrs, mod);
> > }
> >
> > /* Is this module of this name done loading? No locks held. */
> > @@ -3562,9 +3559,7 @@ static int load_module(struct load_info *info, const char __user *uargs,
> > if (err < 0)
> > goto free_modinfo;
> >
> > - err = post_relocation(mod, info);
> > - if (err < 0)
> > - goto free_modinfo;
> > + post_relocation(mod, info);
> >
> > flush_module_icache(mod);
> >
> > @@ -3589,6 +3584,11 @@ static int load_module(struct load_info *info, const char __user *uargs,
> > if (err)
> > goto bug_cleanup;
> >
> > + /* Arch-specific module finalizing. */
> > + err = module_finalize(info->hdr, info->sechdrs, mod);
> > + if (err)
> > + goto bug_cleanup;
>
> goto coming_cleanup;
>
> Otherwise it looks ok. I'll give it a proper look on Monday though.
>
> Miroslav
I'll test this out and see if it fixes the original issue.
--chris
next prev parent reply other threads:[~2016-04-01 16:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 12:05 Bug with paravirt ops and livepatches Chris J Arges
2016-03-29 13:01 ` Miroslav Benes
2016-03-29 13:05 ` Jiri Kosina
2016-04-01 15:01 ` Jiri Kosina
2016-04-01 15:46 ` Miroslav Benes
2016-04-01 16:01 ` Chris J Arges [this message]
2016-04-01 19:07 ` Chris J Arges
2016-04-01 19:35 ` Jiri Kosina
2016-04-04 16:14 ` Josh Poimboeuf
2016-04-04 17:58 ` Jessica Yu
2016-04-05 13:07 ` Miroslav Benes
2016-04-05 13:53 ` Evgenii Shatokhin
2016-04-05 14:24 ` Josh Poimboeuf
2016-04-05 19:19 ` Jessica Yu
2016-04-06 8:30 ` Miroslav Benes
2016-04-06 8:43 ` Miroslav Benes
2016-04-06 9:09 ` Miroslav Benes
2016-04-06 17:23 ` Jessica Yu
2016-04-06 16:55 ` Jessica Yu
2016-04-05 23:27 ` Chris J Arges
2016-04-06 9:09 ` Miroslav Benes
2016-04-06 10:38 ` Chris J Arges
2016-04-06 12:09 ` Miroslav Benes
2016-04-06 13:48 ` Chris J Arges
2016-04-06 14:17 ` Miroslav Benes
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=20160401160113.GA7837@canonical.com \
--to=chris.j.arges@canonical.com \
--cc=eugene.shatokhin@rosalab.ru \
--cc=jeyu@redhat.com \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.cz \
/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