On Thu, 21 Jul 2016, Jessica Yu wrote:
> +++ Miroslav Benes [12/07/16 14:06 +0200]:
> >
> > Is there a problem when you need to generate a dynrela for paravirt code?
> > I mean one does not know during the build of a patch module if paravirt
> > would or would not be
Hi Steven,
I am afraid there is a bug in the current mainline's ftrace when dynamic
fops are involved.
ftrace_shutdown() relies on schedule_on_each_cpu() which should ensure
that no task stays in a ftrace handler. This was sufficient for a long
time because every handler was called with the pr
On Mon, 8 Aug 2016, Steven Rostedt wrote:
> On Mon, 8 Aug 2016 10:57:45 +0200 (CEST)
> Miroslav Benes wrote:
>
> > Hi Steven,
> >
> > I am afraid there is a bug in the current mainline's ftrace when dynamic
> > fops are involved.
>
> I'm sorr
On Wed, 24 Aug 2016, Josh Poimboeuf wrote:
> There's no reliable way to determine which module tainted the kernel
> with CONFIG_LIVEPATCH. For example, /sys/module//taint
> doesn't report it. Neither does the "mod -t" command in the crash tool.
>
> Make it crystal clear who the guilty party is
On Thu, 25 Aug 2016, Josh Poimboeuf wrote:
> On Thu, Aug 25, 2016 at 04:25:15PM +0200, Miroslav Benes wrote:
> > On Wed, 24 Aug 2016, Josh Poimboeuf wrote:
> >
> > > There's no reliable way to determine which module tainted the kernel
> > > with CONFIG_LIVEP
flag gets set when the module is loaded rather
> than when it's enabled.
>
> I also renamed find_livepatch_modinfo() to check_modinfo_livepatch() to
> better reflect its purpose: it's basically a livepatch-specific
> sub-function of check_modinfo().
>
> Reported-by: Chunyu Hu
> Signed-off-by: Josh Poimboeuf
Acked-by: Miroslav Benes
Miroslav
+
> + /* No found, add the newly allocated one */
> + klp_shadow_add(new_shadow);
> + spin_unlock_irqrestore(&klp_shadow_lock, flags);
> +
> + return new_shadow->data;
> +
> +err_exists:
> + WARN(1, "Duplicate shadow variable <%p, %lx>\n", obj, id);
> +err:
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(klp_shadow_attach);
Otherwise it looks good. You can add my
Acked-by: Miroslav Benes
with those nits fixed.
Thanks,
Miroslav
On Tue, 10 Oct 2017, Josh Poimboeuf wrote:
> On Tue, Oct 10, 2017 at 11:15:33AM -0400, Jason Baron wrote:
> >
> >
> > On 10/06/2017 05:22 PM, Josh Poimboeuf wrote:
> > > On Wed, Sep 27, 2017 at 11:41:29PM -0400, Jason Baron wrote:
> > >> In preparation to introducing atomic replace, introduce it
On Tue, 10 Oct 2017, Jason Baron wrote:
>
>
> On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
> > On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote:
> >> Since 'atomic replace' has completely replaced all previous livepatch
> >> modules, it explicitly disables all previous livepatch modu
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index b9628e4..b7f77be 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -608,6 +608,7 @@ static int klp_init_func(struct klp_object *obj, struct
> klp_func *func)
> INIT_LIST_HEAD(&func->stack_node
On Tue, 17 Oct 2017, Miroslav Benes wrote:
> On Tue, 10 Oct 2017, Jason Baron wrote:
>
> >
> >
> > On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
> > > On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote:
> > >> Since 'atomic repla
Signed-off-by: Miroslav Benes
---
kernel/livepatch/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/livepatch/Kconfig b/kernel/livepatch/Kconfig
index 045022557936..ec4565122e65 100644
--- a/kernel/livepatch/Kconfig
+++ b/kernel/livepatch/Kconfig
@@ -10,6 +10,7 @@ config
On Fri, 26 May 2017, Josh Poimboeuf wrote:
> On Thu, May 18, 2017 at 02:00:43PM +0200, Miroslav Benes wrote:
> > @@ -591,3 +591,19 @@ void klp_send_fake_signal(void)
> > }
> > read_unlock(&tasklist_lock);
> > }
> > +
> > +/*
> > + * Drop
, sending the fake signal is not automatic. It is done only when
admin requests it by writing 1 to signal sysfs attribute in livepatch
sysfs directory.
Signed-off-by: Miroslav Benes
Cc: Oleg Nesterov
Cc: Michael Ellerman
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
: Miroslav Benes
---
Documentation/ABI/testing/sysfs-kernel-livepatch | 10 +
Documentation/livepatch/livepatch.txt| 24 +++--
kernel/livepatch/core.c | 27
kernel/livepatch/transition.c| 25
idle tasks in klp_force_transitions() too - Josh
Miroslav Benes (2):
livepatch: send a fake signal to all blocking tasks
livepatch: force transition process to finish
Documentation/ABI/testing/sysfs-kernel-livepatch | 19 +++
Documentation/livepatch/livepatch.txt| 21
On Fri, 20 Oct 2017, Petr Mladek wrote:
> __klp_disable_patch() should never be called when the patch is not
> enabled. Let's add the same warning that we have in __klp_enable_patch().
>
> This allows to remove the check when calling klp_pre_unpatch_callback().
> It was strange anyway because it
> +/*
> + * Sends a fake signal to all non-kthread tasks with TIF_PATCH_PENDING set.
> + * Kthreads with TIF_PATCH_PENDING set are woken up. Only admin can request
> this
> + * action currently.
> + */
> +void klp_force_signals(void)
> +{
> + struct task_struct *g, *task;
> +
> + pr_notic
On Wed, 1 Nov 2017, Oleg Nesterov wrote:
> On 11/01, Petr Mladek wrote:
> >
> > On Tue 2017-10-31 12:48:52, Miroslav Benes wrote:
> > > + if (task->flags & PF_KTHREAD) {
> > > + /*
> > > + * Wa
On Thu, 2 Nov 2017, Josh Poimboeuf wrote:
> On Tue, Oct 31, 2017 at 12:48:52PM +0100, Miroslav Benes wrote:
> > +
> > +/*
> > + * Sends a fake signal to all non-kthread tasks with TIF_PATCH_PENDING set.
> > + * Kthreads with TIF_PATCH_PENDING set are woken up. Only
On Thu, 2 Nov 2017, Josh Poimboeuf wrote:
> On Tue, Oct 31, 2017 at 12:48:52PM +0100, Miroslav Benes wrote:
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index bf8c8fd72589..b7c60662baf3 100644
> > --- a/kernel/livepatch/core.c
> > ++
On Thu, 2 Nov 2017, Josh Poimboeuf wrote:
> On Tue, Oct 31, 2017 at 12:48:53PM +0100, Miroslav Benes wrote:
> > If a task sleeps in a set of patched functions uninterruptedly, it could
> > block the whole transition process indefinitely. Thus it may be useful
> > to clear
On Tue, 17 Oct 2017, Jason Baron wrote:
>
>
> On 10/17/2017 09:50 AM, Miroslav Benes wrote:
> > On Tue, 17 Oct 2017, Miroslav Benes wrote:
> >
> >> On Tue, 10 Oct 2017, Jason Baron wrote:
> >>
> >>>
> >>>
> >>> On 10/0
On Wed, 18 Oct 2017, Josh Poimboeuf wrote:
> On Wed, Oct 18, 2017 at 11:10:09AM +0200, Miroslav Benes wrote:
> > 3. Drop immediate. It causes problems only and its advantages on x86_64
> > are theoretical. You would still need to solve the interaction with atomic
>
h/ for examples.
>
> Signed-off-by: Joe Lawrence
Acked-by: Miroslav Benes
Miroslav
On Wed, 18 Oct 2017, Josh Poimboeuf wrote:
> On Wed, Oct 18, 2017 at 03:36:42PM +0200, Jiri Kosina wrote:
> > On Wed, 18 Oct 2017, Miroslav Benes wrote:
> >
> > > 3. Drop immediate. It causes problems only and its advantages on x86_64
> > > are theoretical.
On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> On Wed, Oct 11, 2017 at 09:42:09AM -0300, Joao Moreira wrote:
> > > Sounds good! For klp-convert to be successful, we really need a
> > > strategy for dealing with such optimizations. I'm thinking that a
> > > '-fpreserve-function-abi' flag would be t
On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> On Thu, Oct 19, 2017 at 03:24:51PM +0200, Miroslav Benes wrote:
> > On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> >
> > > On Wed, Oct 11, 2017 at 09:42:09AM -0300, Joao Moreira wrote:
> > > > > Sounds good! For
On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> On Thu, Oct 19, 2017 at 04:27:31PM +0200, Miroslav Benes wrote:
> > On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> > > > I think that klp-convert can work with both. Even with non-source-based
> > > > solution you
On Fri, 10 Aug 2018, Torsten Duwe wrote:
> Based on ftrace with regs, do the usual thing. Also allocate a
> task flag for whatever consistency handling is implemented.
> Watch out for interactions with the graph tracer.
> This code has been compile-tested, but has not yet seen any
> heavy livepatc
On Tue, 28 Aug 2018, Petr Mladek wrote:
> livepatch: Atomic replace feature
>
> 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
heck in klp_try_switch_task(),
> as its not required.
>
> Signed-off-by: Kamalesh Babulal
Acked-by: Miroslav Benes
M
Being somewhat late to the party I missed all the fun...
On Wed, 10 May 2017, Josh Poimboeuf wrote:
> On Wed, May 10, 2017 at 06:04:23PM +0200, Petr Mladek wrote:
>
> > IMHO, the point is that RCU must be aware when we call
> > rcu_read_lock()/unlock().
> >
> > My understanding is that rcu_irq
On Mon, 8 May 2017, Steven Rostedt wrote:
> On Mon, 8 May 2017 14:47:29 -0500
> Josh Poimboeuf wrote:
>
> > > Although you should have:
> > >
> > > if (WARN_ONCE(!rcu_is_watching,
> > > "Livepatch ..."))
> > > return;
> > >
> > > or something to not cause any dama
> 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.
I agree. I don't see a good solution to the problem. Imagine a crazy
situation in which someone would like to patch the ent
c()
> is empty. It must be updated when a particular dynamic
> klp_func_type is introduced.
>
> Signed-off-by: Jason Baron
> [pmla...@suse.com: Converted into a generic API]
> Signed-off-by: Petr Mladek
> Cc: Josh Poimboeuf
> Cc: Jessica Yu
> Cc: Jiri Kosina
> Cc: Miro
> +void klp_unpatch_object(struct klp_object *obj, enum klp_func_type ftype)
> {
> struct klp_func *func;
> + bool patched = false;
>
> - klp_for_each_func(obj, func)
> - if (func->patched)
> + klp_for_each_func(obj, func) {
> + if (!func->patched)
> +
On Thu, 25 Jan 2018, Petr Mladek wrote:
> From: Jason Baron
>
> We are going to add a feature called atomic replace. It will allow to
> create a patch that would replace all already registered patches.
>
> The replaced patches will stay registered because they are typically
> unregistered by so
On Thu, 25 Jan 2018, Petr Mladek wrote:
> 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 a
> -struct klp_object *klp_get_or_add_object(struct klp_patch *patch,
> +static struct klp_object *klp_get_or_add_object(struct klp_patch *patch,
> struct klp_object *old_obj)
A nit, but this change belongs to 3/6, doesn't it?
> {
> struct klp_
On Thu, 1 Feb 2018, Joe Lawrence wrote:
> On 02/01/2018 08:49 AM, Miroslav Benes wrote:
> >
> > Well, one more thing. I think there is a problem with shadow variables.
> > Similar to callbacks situation. Shadow variables cannot be destroyed the
> > way it is shown
On Thu, 1 Feb 2018, Josh Poimboeuf wrote:
> On Thu, Feb 01, 2018 at 04:08:14PM +0100, Miroslav Benes wrote:
> > On Thu, 1 Feb 2018, Joe Lawrence wrote:
> >
> > > On 02/01/2018 08:49 AM, Miroslav Benes wrote:
> > > >
> > > > Well, one more thing.
y any
new live patches and should plan for reboot into an updated kernel.
The architectures would now need to provide HAVE_RELIABLE_STACKTRACE to
fully support livepatch.
Signed-off-by: Miroslav Benes
---
v2 changes:
- 2/2 from v1 dropped
- documentation
Documentation/livepatch/livepatc
On Tue, 10 Apr 2018, Josh Poimboeuf wrote:
> > > I agree here. Practically we use only cumulative replacement patches at
> > > SUSE. So with that in mind I don't care about the stacking much. But, it
> > > may make sense for someone else. Evgenii mentioned they used it for
> > > hotfixes. Therefor
On Tue, 10 Apr 2018, Josh Poimboeuf wrote:
> On Tue, Apr 10, 2018 at 10:34:55AM +0200, Petr Mladek wrote:
> > > > > > > We were just recently discussing the possibility of not allowing
> > > > > > > the
> > > > > > > disabling of patches at all. If we're not going that far, let's
> > > > > > >
On Thu, 5 Apr 2018, Petr Mladek wrote:
> The existing API allows to pass a sample data to initialize the shadow
> data. It works well when the data are position independent. But it fails
> miserably when we need to set a pointer to the shadow structure itself.
>
> Unfortunately, we might need to
On Wed, 11 Apr 2018, Josh Poimboeuf wrote:
> On Wed, Apr 11, 2018 at 10:07:31AM +0200, Miroslav Benes wrote:
> > > > I was confused by wording "in the middle". It suggested that there
> > > > might had been enabled patches on the top and the bottom of the st
> Questions for v3:
>
> - Should we split off the atomic replace and shadow variable update
> tests so that the this patchset could be merged before the ones
> listed above?
What Josh said. If we merge it almost together, there is no need to split
it.
> - I didn't remove any of the
Hi,
On Thu, 12 Apr 2018, Joe Lawrence wrote:
> Add a few livepatch modules and simple target modules that the included
> regression suite can run tests against.
Could you include a brief description which features are tested?
> Signed-off-by: Joe Lawrence
> ---
> diff --git a/lib/livepatch/t
On Mon, 12 Mar 2018, Joe Lawrence wrote:
> These are the callback tests that I hacked up into a livepatch
> kselftest. (Basically I copied a bunch of the sample modules and
> verified the expected dmesg output as I had listed in in the
> Documentation/livepatch/callbacks.txt file.) The script is
> > I don't know, does anybody really care about this case (patching on top
> > of a disabled patch)? It just adds to the crazy matrix of possible
> > scenarios we have to keep in our heads, which means more bugs, for very
> > little (hypothetical) gain.
>
> It depends if the we remove the repla
> @@ -186,10 +198,13 @@ static void *__klp_shadow_get_or_alloc(void *obj,
> unsigned long id, void *data,
> * Return: the shadow variable data element, NULL on duplicate or
> * failure.
> */
> -void *klp_shadow_alloc(void *obj, unsigned long id, void *data,
> -size_t siz
On Wed, 14 Mar 2018, Josh Poimboeuf wrote:
> On Tue, Mar 13, 2018 at 04:54:48PM +0100, Petr Mladek wrote:
> > We might need to do some actions before the shadow variable is freed.
> > For example, we might need to remove it from a list or free some data
> > that it points to.
> >
> > This is alre
> > +* see klp_init_object_loaded().
> > +*/
> > + if (!func->new_func && !func->nop)
> > return -EINVAL;
>
> >
> > INIT_LIST_HEAD(&func->stack_node);
> > @@ -742,6 +920,9 @@ static int klp_init_object_loaded(struct klp_patch
> > *patch,
> > return
to klp_is_patch_on_stack() and used in __klp_enable_patch()
> as a new sanity check.
>
> This patch does not change the existing behavior.
In my opinion it could be easier for a review to squash the patch into the
next one.
> Signed-off-by: Petr Mladek
> Cc: Josh Poimboeuf
> Cc:
On Fri, 23 Mar 2018, Petr Mladek wrote:
> Replaced patches are removed from the stack when the transition is
> finished. It means that Nop structures will never be needed again
> and can be removed. Why should we care?
>
> + Nop structures make false feeling that the function is patched
> e
> > > > I think you're missing my point. This isn't about your patch set, per
> > > > se. It's really about our existing code. Today, our patch stack
> > > > doesn't follow real stack semantics, because patches in the middle might
> > > > be disabled. I see that as a problem.
> >
> > No, plea
> > > I love this. Nice work!
Yes, it looks really good.
> > > As you and Petr discussed, it would be nice to get rid of some of the
> > > delays, and also the callback tests will be very important.
> >
> > I've got v2 WIP that minimizes the delays, cleans up build flags, and
> > adds a basic
On Mon, 15 Oct 2018, Petr Mladek wrote:
> +static int klp_add_object_nops(struct klp_patch *patch,
> +struct klp_object *old_obj)
> +{
> + struct klp_object *obj;
> + struct klp_func *func, *old_func;
> +
> + obj = klp_find_object(patch, old_obj);
> +
> +
On Thu, 22 Nov 2018, Jessica Yu wrote:
> +++ Vincent Whitchurch [22/11/18 13:24 +0100]:
> >On Thu, Nov 22, 2018 at 12:01:54PM +, Dave Martin wrote:
> >> On Mon, Nov 19, 2018 at 05:25:12PM +0100, Vincent Whitchurch wrote:
> >> > st_info is currently overwritten after relocation and used to stor
On Wed, 24 Oct 2018, Petr Mladek wrote:
> On Thu 2018-10-18 07:58:24, Josh Poimboeuf wrote:
> > On Thu, Oct 18, 2018 at 01:11:53PM +0200, Petr Mladek wrote:
> > > On Wed 2018-10-17 13:17:56, Josh Poimboeuf wrote:
> > > > On Mon, Oct 15, 2018 at 02:37:03PM +0200, Petr Mladek wrote:
> > > > > The de
> -/*
> - * Free all functions' kobjects in the array up to some limit. When limit is
> - * NULL, all kobjects are freed.
> - */
> -static void klp_free_funcs_limited(struct klp_object *obj,
> -struct klp_func *limit)
> +static void klp_free_funcs(struct klp_object *
On Wed, 21 Nov 2018, Jessica Yu wrote:
> The module loader internally works with both exported symbols
> represented as struct kernel_symbol, as well as Elf symbols from a
> module's symbol table. It's hard to distinguish sometimes which type of
> symbol we're handling given that some helper funct
On Thu, 22 Nov 2018, Jessica Yu wrote:
> +++ Miroslav Benes [22/11/18 11:19 +0100]:
> >On Wed, 21 Nov 2018, Jessica Yu wrote:
> >
> >> The module loader internally works with both exported symbols
> >> represented as struct kernel_symbol, as well as Elf symbols
l?
>
> Clean up and unify the function naming scheme a bit to make it clear
> which kind of symbol we're handling. This change only affects static
> functions internal to the module loader.
>
> Signed-off-by: Jessica Yu
Reviewed-by: Miroslav Benes
M
because kobject free callbacks are called
> asynchronously. We could not wait for them easily. Fortunately, we do
> not have to. Any further access can be avoided by removing them from
> the dynamic lists.
>
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
M
On Thu, 29 Nov 2018, Petr Mladek wrote:
> User documentation for the atomic replace feature. It makes it easier
> to maintain livepatches using so-called cumulative patches.
>
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
M
e time after the transition finishes. It might help
> to catch obvious mistakes. But more importantly, we do not need to
> handle situation when a patch in the middle of the function stack
> (ops->func_stack) is being removed.
>
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
M
allbacks
> - shadow variable API
>
> Signed-off-by: Joe Lawrence
> Signed-off-by: Petr Mladek
Tested-by: Miroslav Benes
I can also ack the changes in Documentation/, but probably someone else should
look at the selftests.
Miroslav
On Thu, 6 Dec 2018, Petr Mladek wrote:
> On Mon 2018-12-03 16:29:32, Miroslav Benes wrote:
> > You probably forgot to replace the subject with Josh's proposal.
> >
> > > module_put() is currently never called in klp_complete_transition() when
> > > klp_fo
On Thu, 6 Dec 2018, Petr Mladek wrote:
> On Wed 2018-12-05 14:32:53, Joe Lawrence wrote:
> > > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > > index 972520144713..e01dfa3b58d2 100644
> > > --- a/kernel/livepatch/core.c
> > > +++ b/kernel/livepatch/core.c
> > > @@ -45,7 +45,7 @
> > I don't have many code comments as the changes appear to safely and
> > correctly do what the say. (We are at v14 after all :) I mainly
> > compared the text and comments to the implementation and noted typos
> > (marked by substitution s/old/new) and awkward wordings (marked by
> > "re-wor
t_size is neither used by the module core nor by any
> architecture.
>
> Reviewed-by: Dave Martin
> Signed-off-by: Vincent Whitchurch
Reviewed-by: Miroslav Benes
M
+--
> kernel/livepatch/core.c | 6 +++---
> kernel/livepatch/patch.c | 18 ++
> kernel/livepatch/patch.h | 2 +-
> kernel/livepatch/transition.c | 4 ++--
> 5 files changed, 18 insertions(+), 16 deletions(-)
kernel/livepatch/patch.h also mentions old_addr in a comment.
You can add
Acked-by: Miroslav Benes
with that fixed.
Miroslav
; This patch does not change the code except of two forward declarations.
>
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
M
On Thu, 29 Nov 2018, Petr Mladek wrote:
> -static int klp_init_patch(struct klp_patch *patch)
> +/* Init operations that must succeed before klp_free_patch() can be called.
> */
> +static int klp_init_patch_before_free(struct klp_patch *patch)
There is no klp_free_patch() now, so the comment is
You probably forgot to replace the subject with Josh's proposal.
> module_put() is currently never called in klp_complete_transition() when
> klp_force is set. As a result, we might keep the reference count even when
> klp_enable_patch() fails and klp_cancel_transition() is called.
Correct.
> Th
Mainly nits below. Overall it looks good.
> The possibility to re-enable a registered patch was useful for immediate
> patches where the livepatch module had to stay until the system reboot.
> The improved consistency model allows to achieve the same result by
> unloading and loading the livepatch
m: Initialize lists before init calls]
> Signed-off-by: Petr Mladek
> Cc: Josh Poimboeuf
> Cc: Jessica Yu
> Cc: Jiri Kosina
> Cc: Miroslav Benes
Acked-by: Miroslav Benes
M
+See Documentation/livepatch/cumulative-patches.txt for more details.
which is added later in the series.
The rest looks good, so
Acked-by: Miroslav Benes
M
On Tue, 4 Dec 2018, Petr Mladek wrote:
> On Tue 2018-12-04 13:54:55, Miroslav Benes wrote:
> > > diff --git a/Documentation/livepatch/livepatch.txt
> > > b/Documentation/livepatch/livepatch.txt
> > > index 2d7ed09dbd59..d849af312576 100644
> > > ---
On Mon, 17 Dec 2018, Joe Lawrence wrote:
> On 12/17/2018 07:03 AM, Miroslav Benes wrote:
> > Hi,
> >
> > I'm sorry for being late to the party.
> >
> > On Sun, 16 Dec 2018, Nicholas Mc Guire wrote:
> >
> >> Sparse reported warnings abou
On Mon, 17 Dec 2018, Nicholas Mc Guire wrote:
> On Mon, Dec 17, 2018 at 10:44:36AM -0500, Joe Lawrence wrote:
> > On 12/17/2018 07:03 AM, Miroslav Benes wrote:
> > > Hi,
> > >
> > > I'm sorry for being late to the party.
> > >
On Mon, 17 Dec 2018, Josh Poimboeuf wrote:
> On Mon, Dec 17, 2018 at 04:06:18PM -0800, Andi Kleen wrote:
> > On Mon, Dec 17, 2018 at 05:36:44PM -0500, Steven Rostedt wrote:
> > > On Mon, 17 Dec 2018 15:31:26 -0600
> > > Josh Poimboeuf wrote:
> > >
> > > > On Mon, Dec 17, 2018 at 08:29:38PM +0100
GCC 9 introduces a new option, -flive-patching. It disables certain
optimizations which could make a compilation unsafe for later live
patching of the running kernel.
The option is used only if CONFIG_LIVEPATCH is enabled and $(CC)
supports it.
Signed-off-by: Miroslav Benes
---
Makefile | 4
On Thu, 13 Dec 2018, Josh Poimboeuf wrote:
> On Mon, Dec 03, 2018 at 03:59:57PM +0100, Miroslav Benes wrote:
> > On Thu, 29 Nov 2018, Petr Mladek wrote:
> >
> > > -static int klp_init_patch(struct klp_patch *patch)
> > > +/* Init operations that must succe
Petr Mladek for
> catching this) and NULL returned.
>
> Signed-off-by: Nicholas Mc Guire
> Fixes: 439e7271dc2b ("livepatch: introduce shadow variable API")
Acked-by: Miroslav Benes
M
Hi,
I'm sorry for being late to the party.
On Sun, 16 Dec 2018, Nicholas Mc Guire wrote:
> Sparse reported warnings about non-static symbols. For the variables
> a simple static attribute is fine - for those symbols referenced by
> livepatch via klp_func the symbol-names must be unmodified in th
On Wed, 19 Dec 2018, Jiri Kosina wrote:
> On Wed, 19 Dec 2018, Josh Poimboeuf wrote:
>
> > Also the commit message needs an analysis of the performance impacts.
>
> Agreed. Especially as it's expected (*) to be completely in the noise
> particularly for the kernel, it'd be good to have that doc
On Thu, 20 Dec 2018, Josh Poimboeuf wrote:
> On Thu, Dec 20, 2018 at 09:33:05AM +0100, Miroslav Benes wrote:
> > > > Though, upstream, almost everybody seems to use kpatch-build, for which
> > > > this patch doesn't help. And people will continue to do so unt
On Thu, 20 Dec 2018, Joao Moreira wrote:
> On 12/20/18 12:33 AM, Miroslav Benes wrote:
> > On Wed, 19 Dec 2018, Jiri Kosina wrote:
> >
> >> On Wed, 19 Dec 2018, Josh Poimboeuf wrote:
> >>
> >>> Also the commit message needs an analysis of the perform
Commit 6b7e633fe9c2 ("tracing: Remove extra zeroing out of the ring
buffer page") removed the only caller of ring_buffer_page_len(). The
function is now unused and may be removed.
Signed-off-by: Miroslav Benes
---
I am sorry if you received the patch more than once (hopefully not)
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index dd23655fda3a..490e56070a7e 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -461,5 +461,15 @@ int module_finalize(const Elf_Ehdr *hdr,
> #endif
> }
>
> +#ifdef CONFIG_LIVEPATCH
>
On Mon, 1 Oct 2018, Torsten Duwe wrote:
> Based on ftrace with regs, do the usual thing. Also allocate a
> task flag for whatever consistency handling will be used.
> Watch out for interactions with the graph tracer.
Similar to what Mark wrote about 2/4, I'd appreciate a better commit log.
Could
4/include/asm/module.h | 8 +---
> > arch/arm64/kernel/module-plts.c | 36
> > arch/arm64/kernel/module.c | 9 +----
> > 3 files changed, 30 insertions(+), 23 deletions(-)
>
> Actually, I guess I should just queue this for 4.21 given that it's
> completely self-contained.
FWIW you can also add my
Reviewed-by: Miroslav Benes
Thanks, Jessica.
Miroslav
Hi,
On Fri, 26 Oct 2018, Torsten Duwe wrote:
> Based on ftrace with regs, do the usual thing.
> (see Documentation/livepatch/livepatch.txt)
>
> Use task flag bit 6 to track patch transisiton state for the consistency
> model. Add it to the work mask so it gets cleared on all kernel exits to
> us
On Fri, 12 Oct 2018, Petr Mladek wrote:
> On Wed 2018-09-05 11:34:06, Miroslav Benes wrote:
> > On Tue, 28 Aug 2018, Petr Mladek wrote:
> > > Also the API and logic is much easier. It is enough to call
> > > klp_enable_patch() in module_init() call. The patch pat
> >Does this mean we can drop the plt pointer from this struct altogether, and
> >simply offset into the section headers when applying the relocations?
>
> Hmm, if everyone is OK with dropping the plt pointer from struct
> mod_plt_sec, then I think we can simplify this patch even further.
>
> W
On Tue, 23 Oct 2018, Jessica Yu wrote:
> diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
> index f0690c2ca3e0..05067717dfc5 100644
> --- a/arch/arm64/kernel/module-plts.c
> +++ b/arch/arm64/kernel/module-plts.c
> @@ -210,9 +210,15 @@ int module_frob_arch_sections(Elf
On Thu, 25 Oct 2018, Petr Mladek wrote:
> On Tue 2018-10-23 19:55:54, Jessica Yu wrote:
> > The arm64 module loader keeps a pointer into info->sechdrs to keep track
> > of section header information for .plt section(s). A pointer to the
> > relevent section header (struct elf64_shdr) in info->sech
1 - 100 of 815 matches
Mail list logo
