From: Miroslav Benes <mbenes@suse.cz>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
Petr Mladek <pmladek@suse.com>,
jikos@kernel.org, linux-kernel@vger.kernel.org,
live-patching@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal
Date: Tue, 3 Sep 2019 15:02:34 +0200 (CEST) [thread overview]
Message-ID: <alpine.LSU.2.21.1909031447140.3872@pobox.suse.cz> (raw)
In-Reply-To: <5c649320-a9bf-ae7f-5102-483bc34d219f@redhat.com>
On Mon, 2 Sep 2019, Joe Lawrence wrote:
> On 9/2/19 12:13 PM, Miroslav Benes wrote:
> >> I can easily foresee more problems like those in the future. Going
> >> forward we have to always keep track of which special sections are
> >> needed for which architectures. Those special sections can change over
> >> time, or can simply be overlooked for a given architecture. It's
> >> fragile.
> >
> > Indeed. It bothers me a lot. Even x86 "port" is not feature complete in
> > this regard (jump labels, alternatives,...) and who knows what lurks in
> > the corners of the other architectures we support.
> >
> > So it is in itself reason enough to do something about late module
> > patching.
> >
>
> Hi Miroslav,
>
> I was tinkering with the "blue-sky" ideas that I mentioned to Josh the other
> day.
> I dunno if you had a chance to look at what removing that code looks
> like, but I can continue to flesh out that idea if it looks interesting:
Unfortunately no and I don't think I'll come up with something useful
before LPC, so anything is really welcome.
>
> https://github.com/joe-lawrence/linux/tree/blue-sky
>
> A full demo would require packaging up replacement .ko's with a livepatch, as
> well as "blacklisting" those deprecated .kos, etc. But that's all I had time
> to cook up last week before our holiday weekend here.
Frankly, I'm not sure about this approach. I'm kind of torn. The current
solution is far from ideal, but I'm not excited about the other options
either. It seems like the choice is basically between "general but
technically complicated fragile solution with nontrivial maintenance
burden", or "something safer and maybe cleaner, but limiting for
users/distros". Of course it depends on whether the limitation is even
real and how big it is. Unfortunately we cannot quantify it much and that
is probably why our opinions (in the email thread) differ.
Not much constructive email, but I have to think about it some more
(before LPC).
Regards
Miroslav
next prev parent reply other threads:[~2019-09-03 13:02 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
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 [this message]
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=alpine.LSU.2.21.1909031447140.3872@pobox.suse.cz \
--to=mbenes@suse.cz \
--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=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).