From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: jikos@kernel.org, pmladek@suse.com, joe.lawrence@redhat.com,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal
Date: Wed, 14 Aug 2019 10:12:44 -0500 [thread overview]
Message-ID: <20190814151244.5xoaxib5iya2qjco@treble> (raw)
In-Reply-To: <alpine.LSU.2.21.1908141256150.16696@pobox.suse.cz>
On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
> > Really, we should be going in the opposite direction, by creating module
> > dependencies, like all other kernel modules do, ensuring that a module
> > is loaded *before* we patch it. That would also eliminate this bug.
>
> Yes, but it is not ideal either with cumulative one-fixes-all patch
> modules. It would load also modules which are not necessary for a
> customer and I know that at least some customers care about this. They
> want to deploy only things which are crucial for their systems.
If you frame the question as "do you want to destabilize the live
patching infrastucture" then the answer might be different.
We should look at whether it makes sense to destabilize live patching
for everybody, for a small minority of people who care about a small
minority of edge cases.
Or maybe there's some other solution we haven't thought about, which
fits more in the framework of how kernel modules already work.
> We could split patch modules as you proposed in the past, but that have
> issues as well.
Right, I'm not really crazy about that solution either.
Here's another idea: per-object patch modules. Patches to vmlinux are
in a vmlinux patch module. Patches to kvm.ko are in a kvm patch module.
That would require:
- Careful management of dependencies between object-specific patches.
Maybe that just means that exported function ABIs shouldn't change.
- Some kind of hooking into modprobe to ensure the patch module gets
loaded with the real one.
- Changing 'atomic replace' to allow patch modules to be per-object.
> Anyway, that is why I proposed "Rethinking late module patching" talk at
> LPC and we should try to come up with a solution there.
Thanks, I saw that. It's definitely worthy of more discussion. The
talk may be more productive if there were code to look at. For example,
a patch which removes all the "late module patching" gunk, so we can at
least quantify the cost of the current approach.
--
Josh
next prev parent reply other threads:[~2019-08-14 15:12 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 12:28 [RFC PATCH 0/2] livepatch: Clear relocation targets on a module removal Miroslav Benes
2019-07-19 12:28 ` [PATCH 1/2] livepatch: Nullify obj->mod in klp_module_coming()'s error path Miroslav Benes
2019-07-28 19:45 ` Josh Poimboeuf
2019-08-19 11:26 ` Petr Mladek
2019-07-19 12:28 ` [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal Miroslav Benes
2019-07-22 9:33 ` Petr Mladek
2019-08-14 12:33 ` Miroslav Benes
2019-07-28 20:04 ` Josh Poimboeuf
2019-08-14 11:06 ` Miroslav Benes
2019-08-14 15:12 ` Josh Poimboeuf [this message]
2019-08-16 9:46 ` Petr Mladek
2019-08-22 22:36 ` Josh Poimboeuf
2019-08-23 8:13 ` Petr Mladek
2019-08-26 14:54 ` Josh Poimboeuf
2019-08-27 15:05 ` Joe Lawrence
2019-08-27 15:37 ` Josh Poimboeuf
2019-09-02 16:13 ` Miroslav Benes
2019-09-02 17:05 ` Joe Lawrence
2019-09-03 13:02 ` Miroslav Benes
2019-09-04 8:49 ` Petr Mladek
2019-09-04 16:26 ` Joe Lawrence
2019-09-05 2:50 ` Josh Poimboeuf
2019-09-05 11:09 ` Petr Mladek
2019-09-05 11:19 ` Jiri Kosina
2019-09-05 13:23 ` Josh Poimboeuf
2019-09-05 13:31 ` Jiri Kosina
2019-09-05 13:42 ` Josh Poimboeuf
2019-09-05 11:39 ` Joe Lawrence
2019-09-05 13:08 ` Josh Poimboeuf
2019-09-05 13:15 ` Josh Poimboeuf
2019-09-05 13:52 ` Petr Mladek
2019-09-05 14:28 ` Josh Poimboeuf
2019-09-05 12:03 ` Miroslav Benes
2019-09-05 12:35 ` Josh Poimboeuf
2019-09-05 12:49 ` Miroslav Benes
2019-09-05 11:52 ` Miroslav Benes
2019-09-05 2:32 ` Josh Poimboeuf
2019-09-05 12:16 ` Miroslav Benes
2019-09-05 12:54 ` Josh Poimboeuf
2019-09-06 12:51 ` Miroslav Benes
2019-09-06 15:38 ` Joe Lawrence
2019-09-06 16:45 ` Josh Poimboeuf
2019-08-26 13:44 ` Nicolai Stange
2019-08-26 15:02 ` Josh Poimboeuf
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=20190814151244.5xoaxib5iya2qjco@treble \
--to=jpoimboe@redhat.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--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 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).