[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.21.1803051352300.26605@pobox.suse.cz>
Date: Mon, 5 Mar 2018 13:54:38 +0100 (CET)
From: Miroslav Benes <mbenes@...e.cz>
To: Evgenii Shatokhin <eshatokhin@...tuozzo.com>
cc: Petr Mladek <pmladek@...e.com>, Jason Baron <jbaron@...mai.com>,
Jiri Kosina <jikos@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Joe Lawrence <joe.lawrence@...hat.com>,
Jessica Yu <jeyu@...nel.org>, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 0/8] livepatch: Atomic replace feature
On Mon, 5 Mar 2018, Evgenii Shatokhin wrote:
> Hi,
Hi,
> > The atomic replace allows to create cumulative patches. They
> > are useful when you maintain many livepatches and want to remove
> > one that is lower on the stack. In addition it is very useful when
> > more patches touch the same function and there are dependencies
> > between them.
>
> I have experimented with this updated patchset a bit.
> It looks like replace operation fails if there is a loaded but disabled patch.
>
> Suppose there are 2 binary patches changing the same kernel functions. Load
> patch1, then disable it (echo 0 > /sys/kernel/livepatch/patch1/enabled), then
> try load patch2 with atomic replace. I get "Device or resource busy" error at
> this point.
>
> It seems, __klp_enable_patch() returns -EBUSY for some reason. I haven't dug
> deeper into that code yet.
Yes, it is "enforce stacking" check in __klp_enable_patch():
/* enforce stacking: only the first disabled patch can be enabled */
if (patch->list.prev != &klp_patches &&
!list_prev_entry(patch, list)->enabled)
return -EBUSY;
So not connected to this patch set. We've had the behaviour for quite some
time.
Miroslav
> A workaround is simple: just unload all disabled patches before trying to load
> patch2 with replace. Still, the behavior is quite strange.
Powered by blists - more mailing lists