From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Jason Baron <jbaron@akamai.com>,
Evgenii Shatokhin <eshatokhin@virtuozzo.com>,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
jeyu@kernel.org, jikos@kernel.org, mbenes@suse.cz,
joe.lawrence@redhat.com
Subject: Re: [PATCH v5 0/3] livepatch: introduce atomic replace
Date: Wed, 31 Jan 2018 16:08:11 -0600 [thread overview]
Message-ID: <20180131220811.isgqpf3gwrsnul5k@treble> (raw)
In-Reply-To: <20180126102326.u5jscbbgburrzatp@pathway.suse.cz>
On Fri, Jan 26, 2018 at 11:23:26AM +0100, Petr Mladek wrote:
> So, we are talking about a lot of rather non-trivial code.
> IMHO, it might be easier to run just the callbacks from
> the new patch. In reality, the author should always know
> what it might be replacing and what needs to be done.
>
> By other words, it might be much easier to handle all
> situations in a single script in the new patch. Alternative
> would be doing crazy hacks to prevent the older scripts from
> destroying what we would like to keep. We would need to
> keep in mind interactions between the scripts and
> the order in which they are called.
>
> Or do you plan to use cumulative patches to simply
> get rid of any other "random" livepatches with something
> completely different? In this case, it might be much more
> safe to disable the older patches a normal way.
>
> I would suggest to just document the current behavior.
> We should create Documentation/livepatch/cummulative-patches.txt
> anyway.
+1. Only the new patch (hopefully) knows the details about what is
being reverted. So it makes sense to ignore the replaced patch's
callbacks, and to only call the new patch's callbacks.
--
Josh
prev parent reply other threads:[~2018-01-31 22:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 19:55 [PATCH v5 0/3] livepatch: introduce atomic replace Jason Baron
2018-01-12 19:55 ` [PATCH v5 1/3] livepatch: use lists to manage patches, objects and functions Jason Baron
2018-01-12 19:55 ` [PATCH v5 2/3] livepatch: shuffle core.c function order Jason Baron
2018-01-12 19:55 ` [PATCH v5 3/3] livepatch: add atomic replace Jason Baron
2018-01-19 15:58 ` [PATCH v5 0/3] livepatch: introduce " Petr Mladek
2018-01-19 19:20 ` Evgenii Shatokhin
2018-01-19 21:10 ` Jason Baron
2018-01-26 10:23 ` Petr Mladek
2018-01-26 11:29 ` Evgenii Shatokhin
2018-01-30 14:03 ` Petr Mladek
2018-01-30 15:06 ` Evgenii Shatokhin
2018-01-30 18:19 ` Jason Baron
2018-01-30 19:24 ` Joe Lawrence
2018-01-30 22:11 ` Jason Baron
2018-01-31 9:14 ` Evgenii Shatokhin
2018-01-31 22:09 ` Joe Lawrence
2018-02-01 13:42 ` Petr Mladek
2018-01-31 14:35 ` Miroslav Benes
2018-01-31 22:08 ` Josh Poimboeuf [this message]
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=20180131220811.isgqpf3gwrsnul5k@treble \
--to=jpoimboe@redhat.com \
--cc=eshatokhin@virtuozzo.com \
--cc=jbaron@akamai.com \
--cc=jeyu@kernel.org \
--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 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.