On 05/14/15 at 05:05pm, Miroslav Benes wrote:
>
> Hi,
>
> I have few nitpicks...
>
> The subject is slightly misleading. We still apply the patch (or the patch
> is already applied to be precise). Only the coming module is not patched
> and won't be patched. So I propose something like
>
> li
On 05/14/15 at 09:30am, Josh Poimboeuf wrote:
> On Thu, May 14, 2015 at 09:51:07AM +0800, Minfei Huang wrote:
> > @@ -891,22 +891,24 @@ static void klp_module_notify_coming(struct klp_patch
> > *patch,
> > int ret;
> >
> > ret = klp_init_object_loaded(patch, obj);
> > - if (ret)
> > -
Hi,
I have few nitpicks...
The subject is slightly misleading. We still apply the patch (or the patch
is already applied to be precise). Only the coming module is not patched
and won't be patched. So I propose something like
livepatch: prevent patch inconsistencies if the coming module notifi
On Thu, May 14, 2015 at 09:51:07AM +0800, Minfei Huang wrote:
> The previous patches can be applied, once the corresponding module is
> loaded. In general, the patch will do relocation (if necessary) and
> obtain/verify function address before we start to enable patch.
>
> There are three differen
The previous patches can be applied, once the corresponding module is
loaded. In general, the patch will do relocation (if necessary) and
obtain/verify function address before we start to enable patch.
There are three different situations in which the coming module notifier
can fail:
1) relocatio
5 matches
Mail list logo
