[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180119155858.2644col4z2uejxs2@pathway.suse.cz>
Date: Fri, 19 Jan 2018 16:58:58 +0100
From: Petr Mladek <pmladek@...e.com>
To: Jason Baron <jbaron@...mai.com>
Cc: linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
jpoimboe@...hat.com, jeyu@...nel.org, jikos@...nel.org,
mbenes@...e.cz
Subject: Re: [PATCH v5 0/3] livepatch: introduce atomic replace
On Fri 2018-01-12 14:55:13, Jason Baron wrote:
> Hi,
>
> While using livepatch, I found that when doing cumulative patches, if a patched
> function is completed reverted by a subsequent patch (back to its original state)
> livepatch does not revert the funtion to its original state. Specifically, if
> patch A introduces a change to function 1, and patch B reverts the change to
> function 1 and introduces changes to say function 2 and 3 as well, the change
> that patch A introduced to function 1 is still present. This could be addressed
> by first completely removing patch A (disable and then rmmod) and then inserting
> patch B (insmod and enable), but this leaves an unpatched window. In discussing
> this issue with Josh on the kpatch mailing list, he mentioned that we could get
> 'atomic replace working properly', and that is the direction of this patchset:
> https://www.redhat.com/archives/kpatch/2017-June/msg00005.html
JFYI, I have spent a lot of time reviewing the patchset this week.
IMHO, it is basically correct. I am just not happy with the design,
namely code symmetry, code duplication, and the way how "dynamic" and "nop"
terms are used.
I have started to play with the code. Otherwise, it was pretty hard
to be sure if another design would work. I think that I have something
useful. But it still need some testing and clean up. I believe that
I would be able to send it next week.
Best Regards,
Petr
PS: Jason, you did a great job. Do not worry. I will keep you as the
author of the patches even when I send an updated version.
Powered by blists - more mailing lists