From: Petr Mladek <pmladek@suse.com>
To: Jason Baron <jbaron@akamai.com>
Cc: Miroslav Benes <mbenes@suse.cz>,
Josh Poimboeuf <jpoimboe@redhat.com>,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
jeyu@kernel.org, jikos@kernel.org
Subject: Re: [PATCH v3 2/2] livepatch: add atomic replace
Date: Fri, 20 Oct 2017 09:44:21 +0200 [thread overview]
Message-ID: <20171020074421.GC29163@pathway.suse.cz> (raw)
In-Reply-To: <e8293157-3eed-7264-b27a-db0eaffc881e@akamai.com>
On Thu 2017-10-19 17:44:32, Jason Baron wrote:
> So for atomic replace, it seems as if we don't want to allow replaced
> patches to be re-enabled but instead, allow them to rmmod/insmod'ed to
> allow revert.
>
> In your above proposed model around immediate, if all patches are
> immediate then the atomic replace doesn't allow any of the previous
> patches to be removed from the kernel via rmmod, while if all patches
> are handled using the consistency model then all patches previous to the
> atomic replace patch could be removed via rmmod. So this would simplify
> the logic around when replaced patches could removed.
yes
> I was thinking in the current model to only allow the one preceding
> patch to the atomic replace patch to be rmmod'able, if the atomic
> replace patch was using the consistency model (to avoid complications
> with immediate functions/patches). And this could be extended to all
> *all* patches previous to the atomic replace patch to be rmmod'able when
> we move to the proposed model around immediates. So I don't think this
> should hold up the atomic replace patches?
Yes, this sounds reasonable from the atomic replace patch point of view.
Well, the consistency model is broken at the moment when immediate
flag is used. We should fix this ASAP. IMHO, the fix might need to go
upstream before the atomic replace feature. It might be even stable
material.
Best Regards,
Petr
PS: One problem is that there are some conferences (Kernel Summit,
Open Source Summit) next week. At least all livepatch-related SUSE
people will be less reachable.
next prev parent reply other threads:[~2017-10-20 7:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 3:41 [PATCH v3 0/2] livepatch: introduce " Jason Baron
2017-09-28 3:41 ` [PATCH v3 1/2] livepatch: Add dynamic klp_object and klp_func iterators Jason Baron
2017-10-06 21:22 ` Josh Poimboeuf
2017-10-10 15:15 ` Jason Baron
2017-10-11 2:51 ` Josh Poimboeuf
2017-10-16 14:47 ` Miroslav Benes
2017-09-28 3:41 ` [PATCH v3 2/2] livepatch: add atomic replace Jason Baron
2017-10-06 22:32 ` Josh Poimboeuf
2017-10-10 17:27 ` Jason Baron
2017-10-17 9:02 ` Miroslav Benes
2017-10-17 13:50 ` Miroslav Benes
2017-10-18 3:33 ` Jason Baron
2017-10-18 9:10 ` Miroslav Benes
2017-10-18 11:05 ` Josh Poimboeuf
2017-10-18 11:29 ` Miroslav Benes
2017-10-18 11:25 ` Petr Mladek
2017-10-19 21:44 ` Jason Baron
2017-10-20 7:44 ` Petr Mladek [this message]
2017-10-20 8:59 ` Miroslav Benes
2017-10-18 13:36 ` Jiri Kosina
2017-10-18 16:14 ` Josh Poimboeuf
2017-10-19 8:30 ` Miroslav Benes
2017-10-19 10:57 ` Josh Poimboeuf
2017-10-19 21:52 ` Jason Baron
2017-10-20 9:03 ` Miroslav Benes
2017-10-17 14:27 ` Petr Mladek
2017-10-10 17:19 ` [PATCH v3.1 2/3] livepatch: shuffle core.c function order Jason Baron
2017-10-10 17:19 ` [PATCH v3.1 3/3] livepatch: add atomic replace Jason Baron
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=20171020074421.GC29163@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=jbaron@akamai.com \
--cc=jeyu@kernel.org \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@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
all inboxes | Powered by JetHome®