On Mon, 17 Jun 2019, Peter Zijlstra wrote:
>
> Some module notifiers; such as jump_label_module_notifier(),
> tracepoint_module_notify(); can fail the MODULE_STATE_COMING callback
> (due to -ENOMEM for example). However module.c:prepare_coming_module()
> ignores all such errors, even though this
Hi Joe,
first, I'm sorry for the lack of response so far.
Maybe you've already noticed but the selftests fail. Well, at least in
my VM. When test_klp_convert1.ko is loaded, the process is killed with
[ 518.041826] BUG: kernel NULL pointer dereference, address:
[ 518.042816]
ff-by: YueHaibing
Reviewed-by: Miroslav Benes
Miroslav
message for 3rd patch [Josh]
Miroslav Benes (2):
stacktrace: Remove weak version of save_stack_trace_tsk_reliable()
Revert "livepatch: Remove reliable stacktrace check in
klp_try_switch_task()"
Petr Mladek (1):
livepatch: Remove duplicate warning about missing reliable
e.h serves the same purpose as the old weak
version of save_stack_trace_tsk_reliable() which is therefore no longer
needed.
Cc: Thomas Gleixner
Signed-off-by: Miroslav Benes
---
kernel/stacktrace.c | 8
1 file changed, 8 deletions(-)
diff --git a/kernel/stacktrace.c b/kernel/stacktra
only makes sense to reintroduce the compile time checking in
klp_try_switch_task() again and bail out early.
Signed-off-by: Miroslav Benes
---
kernel/livepatch/transition.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transiti
in
klp_try_switch_task().
Signed-off-by: Petr Mladek
[ mbenes: changelog edited ]
Signed-off-by: Miroslav Benes
---
kernel/livepatch/transition.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
index 7e7ef04689d1..cdf318d86dd6 100644
--- a/kernel
> >> -static void module_remove_modinfo_attrs(struct module *mod)
> >> +static void module_remove_modinfo_attrs(struct module *mod, int end)
> >> {
> >>struct module_attribute *attr;
> >>int i;
> >>
> >>for (i = 0; (attr = >modinfo_attrs[i]); i++) {
> >> + if (end >= 0 && i
On Mon, 3 Jun 2019, YueHaibing wrote:
> In module_add_modinfo_attrs if sysfs_create_file
> fails, we forget to free allocated modinfo_attrs
> and roll back the sysfs files.
>
> Fixes: 03e88ae1b13d ("[PATCH] fix module sysfs files reference counting")
> Signed-off-by: YueHaibing
> ---
> v3:
On Thu, 30 May 2019, YueHaibing wrote:
> In module_add_modinfo_attrs if sysfs_create_file
> fails, we forget to free allocated modinfo_attrs
> and roll back the sysfs files.
>
> Fixes: 03e88ae1b13d ("[PATCH] fix module sysfs files reference counting")
> Signed-off-by: YueHaibing
> ---
> v2:
On Fri, 31 May 2019, Petr Mladek wrote:
> On Fri 2019-05-31 14:32:34, Miroslav Benes wrote:
> > On Fri, 31 May 2019, Petr Mladek wrote:
> >
> > > WARN_ON_ONCE() could not be called safely under rq lock because
> > > of console deadlock issues.
> > >
On Fri, 31 May 2019, Petr Mladek wrote:
> The err_buf array uses 128 bytes of stack space. Move it off the stack
> by making it static. It's safe to use a shared buffer because
> klp_try_switch_task() is called under klp_mutex.
>
> Signed-off-by: Petr Mladek
> Acked-
On Fri, 31 May 2019, Petr Mladek wrote:
> WARN_ON_ONCE() could not be called safely under rq lock because
> of console deadlock issues.
>
> It can be simply removed. A better descriptive message is written
> in klp_enable_patch() when klp_have_reliable_stack() fails.
> The remaining debug
upported. Other eventual users might want its own error
> handling as well.
>
> Signed-off-by: Petr Mladek
> Acked-by: Miroslav Benes
> Reviewed-by: Kamalesh Babulal
> ---
> kernel/stacktrace.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/kern
trace code patching
> operations -- and their respective permissions changes -- are protected
> by the text_mutex.
>
> Reported-by: Johannes Erdfelt
> Signed-off-by: Josh Poimboeuf
For the code
Reviewed-by: Miroslav Benes
However, shouldn't the patch be split in two? One adding text_mutex
protection to livepatch and ftrace. The other adding lockdep_assert_held()
and __module_enable_ro()? The current changelog does not mention lockdep
changes at all.
Miroslav
Hi,
I noticed that livepatching selftests fail on our master branch
(https://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching.git/).
...
TEST: busy target module ... not ok
--- expected
+++ result
@@ -7,16 +7,24 @@ livepatch: 'test_klp_callbacks_demo': in
> > > But I think Miroslav's suggestion to revert 1d98a69e5cef would be even
> > > better.
> >
> > AFAIK, Miroslav wanted to point out that your opinion was inconsistent.
>
> How is my opinion inconsistent?
>
> Is there something wrong with the original approach, which was reverted
> with
>
Commit 4d141ab3416d ("livepatch: Remove custom kobject state handling")
removed kobj_added members of klp_func, klp_object and klp_patch
structures. kernel-doc descriptions were omitted by accident. Remove
them.
Reported-by: Kamalesh Babulal
Signed-off-by: Miroslav Benes
---
inc
On Fri, 3 May 2019, Petr Mladek wrote:
> kobject_init() always succeeds and sets the reference count to 1.
> It allows to always free the structures via kobject_put() and
> the related release callback.
>
> Note that the custom kobject state handling was used only
> because we did not know that
On Mon, 6 May 2019, Josh Poimboeuf wrote:
> On Tue, Apr 30, 2019 at 11:10:48AM +0200, Petr Mladek wrote:
> > WARN_ON_ONCE() could not be called safely under rq lock because
> > of console deadlock issues. Fortunately, there is another check
> > for the reliable stacktrace support in
On Fri, 3 May 2019, Joe Lawrence wrote:
> On Tue, Apr 16, 2019 at 01:37:13PM +0200, Miroslav Benes wrote:
> >
> > [ ... snip ... ]
> >
> > Quick look, but it seems quite similar to the problem we had with
> > apply_alternatives(). See arch/x86/kernel
> Testing
> ---
>
> Kernel build configuration
>
> $ egrep LIVEPATCH .config
> CONFIG_HAVE_LIVEPATCH=y
> CONFIG_LIVEPATCH=y
> CONFIG_TEST_LIVEPATCH=m
>
> $ egrep FTRACE .config
> CONFIG_KPROBES_ON_FTRACE=y
> CONFIG_HAVE_KPROBES_ON_FTRACE=y
>
On Tue, 30 Apr 2019, Petr Mladek wrote:
> klp_try_switch_task() is called under klp_mutex. The buffer for
> debugging messages might be static.
>
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
Miroslav
On Tue, 30 Apr 2019, Petr Mladek wrote:
> WARN_ON_ONCE() could not be called safely under rq lock because
> of console deadlock issues. Fortunately, there is another check
> for the reliable stacktrace support in klp_enable_patch().
>
> Signed-off-by: Petr Mladek
Acked-by:
On Tue, 30 Apr 2019, Tobin C. Harding wrote:
> The correct cleanup function after a call to kobject_init_and_add() has
> succeeded is kobject_del() _not_ kobject_put(). kobject_del() calls
> kobject_put().
>
> Use correct cleanup function when removing a kobject.
>
> Signed-off-by: Tobin C.
On Tue, 30 Apr 2019, Greg Kroah-Hartman wrote:
> On Tue, Apr 30, 2019 at 10:15:33AM +1000, Tobin C. Harding wrote:
> > Currently error return from kobject_init_and_add() is not followed by a
> > call to kobject_put(). This means there is a memory leak.
> >
> > Add call to kobject_put() in error
[ adding CCs ]
On Thu, 25 Apr 2019, Josh Poimboeuf wrote:
> Hi all,
>
> On IRC, Peter expressed some concern about -flive-patching, specifically
> that the flag isn't compatible with LTO.
>
> The upstream kernel currently doesn't support LTO, but Android is using
> it with LLVM:
>
>
On Wed, 24 Apr 2019, Josh Poimboeuf wrote:
> On Wed, Apr 24, 2019 at 10:55:50AM +0200, Petr Mladek wrote:
> > WARN_ON_ONCE() could not be called safely under rq lock because
> > of console deadlock issues. Fortunately, simple printk_deferred()
> > is enough because the warning is printed from a
On Wed, 24 Apr 2019, Petr Mladek wrote:
> WARN_ONCE() in the generic save_stack_trace_tsk_reliable() is superfluous.
> The only current user klp_check_stack() writes its own warning when
> -ENOSYS is returned.
>
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
Miroslav
gt; Suggested-by: Josh Poimboeuf
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
Miroslav
[...]
> Result: a small tweak to sympos_sanity_check() to relax its symbol
> uniqueness verification: allow for duplicate
> instances. Now it will only complain when a supplied symbol references
> the same but a different .
>
> diff --git a/scripts/livepatch/klp-convert.c
On Tue, 23 Apr 2019, Joe Lawrence wrote:
> On Wed, Apr 10, 2019 at 11:50:52AM -0400, Joe Lawrence wrote:
> >
> > [ ... snip ... ]
> >
> > +static bool convert_rela(struct section *oldsec, struct rela *r,
> > + struct sympos *sp, struct elf *klp_elf)
> > +{
> > + struct section *sec;
On Thu, 18 Apr 2019, Josh Poimboeuf wrote:
> On Thu, Apr 18, 2019 at 01:29:36PM +0200, Petr Mladek wrote:
> > The commit d0807da78e11d46f ("livepatch: Remove immediate feature") caused
> > that any livepatch was refused when reliable stacktraces were not supported
> > on the given architecture.
>
On Tue, 16 Apr 2019, Joe Lawrence wrote:
> On 4/10/19 11:50 AM, Joe Lawrence wrote:
> > Hi folks,
> >
> > This is the third installment of the klp-convert tool for generating and
> > processing livepatch symbols for livepatch module builds. For those
> > following along at home, archive links
On Tue, 16 Apr 2019, Joe Lawrence wrote:
> On 4/11/19 3:04 PM, Miroslav Benes wrote:
> >
> >> diff --git a/samples/livepatch/Makefile b/samples/livepatch/Makefile
> >> index 2472ce39a18d..8b9b42a258ad 100644
> >> --- a/samples/livepatch/Makefile
> >>
On Tue, 16 Apr 2019, Josh Poimboeuf wrote:
> On Tue, Apr 16, 2019 at 01:47:30PM +0200, Jiri Kosina wrote:
> > On Tue, 12 Feb 2019, Petr Mladek wrote:
> >
> > > > I think I'd rather go in the opposite direction: allow the patches to be
> > > > loaded. Then they can be forced, if needed. That
[...]
> Current behavior
>
>
> Not good. The livepatch successfully builds but crashes on load:
>
> % insmod lib/livepatch/test_klp_static_keys_mod.ko
> % insmod lib/livepatch/test_klp_static_keys.ko
>
> BUG: unable to handle kernel NULL pointer dereference at
On Tue, 16 Apr 2019, Balbir Singh wrote:
> On Wed, Apr 10, 2019 at 11:50:49AM -0400, Joe Lawrence wrote:
> > Hi folks,
> >
> > This is the third installment of the klp-convert tool for generating and
> > processing livepatch symbols for livepatch module builds. For those
> > following along at
On Fri, 12 Apr 2019, shuah wrote:
> On 4/12/19 1:03 AM, Miroslav Benes wrote:
> > On Thu, 11 Apr 2019, Shuah Khan wrote:
> >
> >> TEST_PROGS variable is for test shell scripts and common clean target
> >> in lib.mk doesn't touch them. TEST_GEN_PROGS are remov
> diff --git a/samples/livepatch/Makefile b/samples/livepatch/Makefile
> index 8b9b42a258ad..5fb3280bbdc4 100644
> --- a/samples/livepatch/Makefile
> +++ b/samples/livepatch/Makefile
> @@ -1,4 +1,8 @@
> LIVEPATCH_livepatch-sample := y
> +LIVEPATCH_livepatch-shadow-fix1 := y
>
On Wed, 10 Apr 2019, Joe Lawrence wrote:
> On Wed, Apr 10, 2019 at 11:50:53AM -0400, Joe Lawrence wrote:
> > From: Josh Poimboeuf
> >
> > Define macros KLP_MODULE_RELOC and KLP_SYMPOS in
> > include/linux/livepatch.h to improve user-friendliness of the
> > livepatch annotation process.
> >
> >
On Wed, 10 Apr 2019, Joe Lawrence wrote:
> On Wed, Apr 10, 2019 at 11:50:52AM -0400, Joe Lawrence wrote:
> >
> > [ ... snip ... ]
> >
> > diff --git a/scripts/livepatch/klp-convert.c
> > b/scripts/livepatch/klp-convert.c
> > new file mode 100644
> > index ..62bd26941081
> > ---
On Thu, 11 Apr 2019, Shuah Khan wrote:
> TEST_PROGS variable is for test shell scripts and common clean target
> in lib.mk doesn't touch them. TEST_GEN_PROGS are removed by it.
>
> Fix it to use TEST_PROGS for test shell scripts and TEST_PROGS_EXTENDED
> for common functions.sh.
>
>
> diff --git a/samples/livepatch/Makefile b/samples/livepatch/Makefile
> index 2472ce39a18d..8b9b42a258ad 100644
> --- a/samples/livepatch/Makefile
> +++ b/samples/livepatch/Makefile
> @@ -1,3 +1,4 @@
> +LIVEPATCH_livepatch-sample := y
> obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-sample.o
>
> >> +
> >> +/*
> >> + * livepatch.h - Kernel Live Patching Core
> >> + *
> >> + * Copyright (C) 2016 Josh Poimboeuf
> >> + */
> >> +
> >> +#ifndef _UAPI_LIVEPATCH_H
> >> +#define _UAPI_LIVEPATCH_H
> >> +
> >> +#include
> >
> >
> > Why is this include needed?
> >
> >> +#define KLP_RELA_PREFIX
ed-by: keesc...@chromium.org
> Reviewed-by: keesc...@chromium.org
> Acked-by: rost...@goodmis.org
> Signed-off-by: Joel Fernandes (Google)
Reviewed-by: Miroslav Benes
M
> While we're on the subject, I'm glad to see ongoing activity on
> klp-convert (though I haven't had a chance to follow the discussions).
> What's the status of the rest of the needed bits?
>
> - kgraft-analysis-tool - will this also be submitted for inclusion in
> the kernel tree?
Yes, it
.
The majority of the tests is unaffected. The only significant exception
is the scheduler section which suffers 1-3% degradation.
Evaluated-by: Giovanni Gherdovich
Signed-off-by: Miroslav Benes
---
The patch is based on master branch of the livepatching tree on
git.kernel.org.
Many thanks to Giovanni who
> BTW, something I *just* noticed when putting together that toy out-of-tree
> module to test out multi-object livepatch modules is that we aren't
> considering out-of-tree symbols in Symbols.list.
>
> Perhaps we can save that for v4 or beyond, but maybe we want to re-arrange the
> klp-convert
> >
> > [jmoreira:
> > * split up: move the .livepatch file-based scheme for identifying
> > livepatches to a previous patch, as it was required for correctly
> > building Symbols.list there.
> > ]
> >
> > Signed-off-by: Josh Poimboeuf
> > Signed-
On Wed, 3 Apr 2019, Miroslav Benes wrote:
>
> > > Hmm, maybe I spoke too soon.
> > >
> > > I am having issues if I have a two-object livepatch module in which each
> > > object file needs to specify its own KLP_MODULE_RELOC for the same
> > &
On Wed, 3 Apr 2019, Joe Lawrence wrote:
> On 4/3/19 8:48 AM, Miroslav Benes wrote:
> >
> >> and it looks like the combined KLP_MODULE_RELOC still contains the two
> >> unique symbol position values (2 and 3):
> >>
> >>% objcopy -O binary --only
> > Hmm, maybe I spoke too soon.
> >
> > I am having issues if I have a two-object livepatch module in which each
> > object file needs to specify its own KLP_MODULE_RELOC for the same
> > symbol name.
> >
> > For example: I have test_klp_convert.ko which is comprised of
> >
tested by loading the livepatch-sample module and
> verifying that the sysfs files for the attributes in the default groups
> were created.
>
> Signed-off-by: Kimberly Brown
Acked-by: Miroslav Benes
M
> > +building system, the second is done by a tool called klp-convert, which
> > can be
> > +found in "scripts/livepatch".
> > +
> > +When an unresolved relocation has as target a symbol whose name is also
> > used by
> > +different symbols throughout the kernel, the relocation cannot be
> > [ ... snip ... ]
> > +
> > +/* Checks if sympos is valid, otherwise prints valid sympos list */
> > +static bool valid_sympos(struct sympos *sp)
> > +{
> > + struct symbol_entry *e;
> > + int counter = 0;
> > +
> > + list_for_each_entry(e, , list) {
> > + if
> > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > index fd03d60f6c5a..1e28ad21314c 100644
> > --- a/scripts/Makefile.build
> > +++ b/scripts/Makefile.build
> > @@ -247,6 +247,11 @@ cmd_gen_ksymdeps = \
> > $(CONFIG_SHELL) $(srctree)/scripts/gen_ksymdeps.sh $@ >>
> >
Adding CCs...
On Wed, 30 Jan 2019, Joao Moreira wrote:
> From: Miroslav Benes
>
> Currently, livepatch infrastructure in the kernel relies on
> MODULE_INFO(livepatch, "Y") statement in a livepatch module. Then the
> kernel module loader knows a module is indeed
patch, as it was required for correctly
> building Symbols.list there.
> ]
>
> Signed-off-by: Josh Poimboeuf
> Signed-off-by: Konstantin Khlebnikov
> Signed-off-by: Miroslav Benes
> Signed-off-by: Joao Moreira
I'm definitely not an expert on this topic (and we talked about it in the
past o
e harm as
> the symbols normally referenced from within livepatches are visible at
> this stage. Also due to these requirements, the spot in-between modules
> compilation and the invocation of scripts/Makefile.modpost was picked
> for hooking cmd_klp_map.
>
> The approach based on .livepatch f
> diff --git a/include/uapi/linux/livepatch.h b/include/uapi/linux/livepatch.h
> new file mode 100644
> index ..bc35f85fd859
> --- /dev/null
> +++ b/include/uapi/linux/livepatch.h
> @@ -0,0 +1,28 @@
> +/*
> + * livepatch.h - Kernel Live Patching Core
> + *
> + * Copyright (C) 2016
On Fri, 8 Feb 2019, Kamalesh Babulal wrote:
> Hi Miroslav,
>
> On Fri, Feb 08, 2019 at 10:24:21AM +0100, Miroslav Benes wrote:
> > Hi Kamalesh,
> >
> > On Fri, 8 Feb 2019, Kamalesh Babulal wrote:
> >
> > > On Wed, Feb 06, 2019 at 11:28:32AM +0100, Pe
Hi Kamalesh,
On Fri, 8 Feb 2019, Kamalesh Babulal wrote:
> On Wed, Feb 06, 2019 at 11:28:32AM +0100, Petr Mladek wrote:
> > On Tue 2019-02-05 09:59:33, Josh Poimboeuf wrote:
> > > On Tue, Feb 05, 2019 at 03:33:28AM +0900, Alice Ferrazzi wrote:
> > > > From: Alice Ferrazzi
> > > >
> > > > As a
On Fri, 28 Dec 2018, Steven Rostedt wrote:
> On Fri, 28 Dec 2018 14:38:47 +0100
> Miroslav Benes wrote:
>
> > Commit 6b7e633fe9c2 ("tracing: Remove extra zeroing out of the ring
> > buffer page") removed the only caller of ring_buffer_page_len(). The
>
.
>
> Note, that the error code is not really important even in the real life.
> The use of shadow variables should be transparent for the original
> livepatched code.
>
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
Miroslav
On Mon, 4 Feb 2019, Petr Mladek wrote:
> From: Joe Lawrence
>
> Fixes the following smatch warning:
>
> lib/livepatch/test_klp_shadow_vars.c:47 ptr_id() warn: returning -1 instead
> of -ENOMEM is sloppy
>
> Signed-off-by: Joe Lawrence
> Signed-off-by: Petr
On Tue, 5 Feb 2019, Alice Ferrazzi wrote:
> From: Alice Ferrazzi
>
> As a result of an unsupported operation is better to use EOPNOTSUPP
> as error code.
> ENOSYS is only used for 'invalid syscall nr' and nothing else.
>
> Signed-off-by: Alice Ferrazzi
Acked-by: Miroslav Benes
Miroslav
On Wed, 30 Jan 2019, Petr Mladek wrote:
> On Mon 2019-01-21 13:14:38, Miroslav Benes wrote:
> > Hi,
> >
> > On Wed, 16 Jan 2019, Petr Mladek wrote:
> >
> > > Do not dereference pointers to the shadow variables when either
> > > klp_shadow_all
Joe Lawrence
> Reviewed-by: Petr Mladek
> Acked-by: Miroslav Benes
> Signed-off-by: Jiri Kosina
> Signed-off-by: Sasha Levin
Hi Sasha,
I am not sure what stable policy is, but the patch is for samples/
directory and I do not think it is something which should necessar
On Wed, 23 Jan 2019, Nicholas Mc Guire wrote:
> kzalloc(sizeof(int)) is called for an int object but then
> passed into klp_shadow_alloc() using the size of the pointer.
> This probably is not a problem as it will fit - but it should
> be cleaned (after all this is reference code).
>
>
change Link: tag to
https://lkml.kernel.org/r/ as asked for when we reviewed v2?
With that
Acked-by: Miroslav Benes
M
On Wed, 16 Jan 2019, Petr Mladek wrote:
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 684766d306ad..8e644837e668 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -59,6 +59,17 @@ static bool klp_is_module(struct klp_object *obj)
> return
ck for these state. They have to proceed all listed patches.
>
> Suggested-by: Josh Poimboeuf
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
M
Hi,
On Wed, 16 Jan 2019, Petr Mladek wrote:
> Do not dereference pointers to the shadow variables when either
> klp_shadow_alloc() or klp_shadow_get() fail.
I may misunderstand the patch, so bear with me, please. Is this because of
a possible null pointer dereference? If yes, shouldn't this
: Petr Mladek
Acked-by: Miroslav Benes
M
introduce deadlocks and cause more headaches with
synchronization and cancelling.
Signed-off-by: Miroslav Benes
---
Documentation/livepatch/livepatch.txt | 3 ++-
kernel/livepatch/transition.c | 17 ++---
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git
, no less (Josh)
- the message in klp_send_signals() is printed only once per transition
(Josh)
- the counter is zeroed in klp_start_transition(), so that even
klp_reverse_transition() starts correctly (Petr)
Miroslav Benes (2):
livepatch: Send a fake signal periodically
livepatch: Remove
The fake signal is send automatically now. We can rely on it completely
and remove the sysfs attribute.
Signed-off-by: Miroslav Benes
---
.../ABI/testing/sysfs-kernel-livepatch| 12 ---
Documentation/livepatch/livepatch.txt | 16 ++--
kernel/livepatch/core.c
atches in an random order.
> Namely, klp_check_stack_func() always looks for the function from
> the livepatch that is being disabled. klp_func structures are just
> removed from the related func_stack. Finally, the ftrace handlers
> is removed only when the func_stack becomes empty.
>
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
Miroslav
e 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
Miroslav
ch.
>
> The removal is done by a special function. It combines actions done by
> __disable_patch() and klp_complete_transition(). But it is a fast
> track without all the transaction-related stuff.
>
> Signed-off-by: Jason Baron
> [pmla...@suse.com: Split, reuse existing code, simplified]
> Signed-off-by: Petr Mladek
> Cc: Josh Poimboeuf
> Cc: Jessica Yu
> Cc: Jiri Kosina
> Cc: Miroslav Benes
Acked-by: Miroslav Benes
Miroslav
ns.
>
> + The module could not be removed until the free operation finishes
> and module_put() is called.
>
> + The operation is asynchronous already when the first
> klp_try_complete_transition() fails and another call
> is queued with a delay.
>
> Suggested-by: Josh Poimboeuf
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
Miroslav
y.
>
> Signed-off-by: Petr Mladek
> Acked-by: Joe Lawrence
Acked-by: Miroslav Benes
Miroslav
>
> [*] We need our own flag to track that the kobject was successfully
> added to the hierarchy. Note that kobj.state_initialized only
> indicates that kobject has been initialized, not whether is has
> been added (and needs to be removed on cleanup).
>
> Signe
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)
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 perf
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 until we
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
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 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
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, 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 about non
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
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
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 su
neither used by the module core nor by any
> architecture.
>
> Reviewed-by: Dave Martin
> Signed-off-by: Vincent Whitchurch
Reviewed-by: Miroslav Benes
M
neither used by the module core nor by any
> architecture.
>
> Reviewed-by: Dave Martin
> Signed-off-by: Vincent Whitchurch
Reviewed-by: Miroslav Benes
M
> > 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
> >
> > 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
> >
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
201 - 300 of 1277 matches
Mail list logo
