Re: [PATCH 3/4] x86/unwind: include __schedule() in stack traces

an 'bp' itself. This allows > the unwinder to start one frame higher on the stack, so that it properly > reports __schedule(). > > Reported-by: Miroslav Benes <mbe...@suse.cz> You can also add my Tested-by: Miroslav Benes <mbe...@suse.cz> One ignorant question below. >

Re: [PATCH 3/4] x86/unwind: include __schedule() in stack traces

an 'bp' itself. This allows > the unwinder to start one frame higher on the stack, so that it properly > reports __schedule(). > > Reported-by: Miroslav Benes You can also add my Tested-by: Miroslav Benes One ignorant question below. > Signed-off-by: Josh Poimboeuf > --- >

Re: [PATCH] Documentation/livepatch: remove the limitation for schedule() patching

On Fri, 6 Jan 2017, Josh Poimboeuf wrote: > On Fri, Jan 06, 2017 at 03:00:45PM +0100, Miroslav Benes wrote: > > > > 2. reversion of the process does not work as expected. The kernel > > crashes after the removal of the module. A task very likely slept in > > sc

Re: [PATCH] Documentation/livepatch: remove the limitation for schedule() patching

On Fri, 6 Jan 2017, Josh Poimboeuf wrote: > On Fri, Jan 06, 2017 at 03:00:45PM +0100, Miroslav Benes wrote: > > > > 2. reversion of the process does not work as expected. The kernel > > crashes after the removal of the module. A task very likely slept in > > sc

Re: [PATCH] Documentation/livepatch: remove the limitation for schedule() patching

On Fri, 6 Jan 2017, Petr Mladek wrote: > On Fri 2017-01-06 15:00:45, Miroslav Benes wrote: > > The Limitations section of the documentation describes the impossibility > > to livepatch anything that is inlined to __schedule() function. This had > > been true till 4.9 kernel c

Re: [PATCH] Documentation/livepatch: remove the limitation for schedule() patching

On Fri, 6 Jan 2017, Petr Mladek wrote: > On Fri 2017-01-06 15:00:45, Miroslav Benes wrote: > > The Limitations section of the documentation describes the impossibility > > to livepatch anything that is inlined to __schedule() function. This had > > been true till 4.9 kernel c

[PATCH] Documentation/livepatch: remove the limitation for schedule() patching

try__ call and I cannot imagine a reason to do it anyway. Therefore, remove the paragraphs from the section. Signed-off-by: Miroslav Benes <mbe...@suse.cz> --- FWIW, I also tested this to be sure on top of the consistency model patch set. I patched schedule() function which

[PATCH] Documentation/livepatch: remove the limitation for schedule() patching

try__ call and I cannot imagine a reason to do it anyway. Therefore, remove the paragraphs from the section. Signed-off-by: Miroslav Benes --- FWIW, I also tested this to be sure on top of the consistency model patch set. I patched schedule() function which calls __schedule() (it is impossibl

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

> @@ -740,6 +809,14 @@ int klp_register_patch(struct klp_patch *patch) > return -ENODEV; > > /* > + * Architectures without reliable stack traces have to set > + * patch->immediate because there's currently no way to patch kthreads > + * with the consistency

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

> @@ -740,6 +809,14 @@ int klp_register_patch(struct klp_patch *patch) > return -ENODEV; > > /* > + * Architectures without reliable stack traces have to set > + * patch->immediate because there's currently no way to patch kthreads > + * with the consistency

Re: [PATCH v3 15/15] livepatch: allow removal of a disabled patch

> diff --git a/samples/livepatch/livepatch-sample.c > b/samples/livepatch/livepatch-sample.c > index bb61c65..0625f38 100644 > --- a/samples/livepatch/livepatch-sample.c > +++ b/samples/livepatch/livepatch-sample.c > @@ -89,7 +89,6 @@ static int livepatch_init(void) > > static void

Re: [PATCH v3 15/15] livepatch: allow removal of a disabled patch

> diff --git a/samples/livepatch/livepatch-sample.c > b/samples/livepatch/livepatch-sample.c > index bb61c65..0625f38 100644 > --- a/samples/livepatch/livepatch-sample.c > +++ b/samples/livepatch/livepatch-sample.c > @@ -89,7 +89,6 @@ static int livepatch_init(void) > > static void

Re: [PATCH v3 14/15] livepatch: add /proc//patch_state

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > Expose the per-task patch state value so users can determine which tasks > are holding up completion of a patching operation. > > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Reviewed-by: Miroslav Benes <mbe...@suse.cz> Miroslav

Re: [PATCH v3 14/15] livepatch: add /proc//patch_state

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > Expose the per-task patch state value so users can determine which tasks > are holding up completion of a patching operation. > > Signed-off-by: Josh Poimboeuf Reviewed-by: Miroslav Benes Miroslav

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > +void klp_start_transition(void) > +{ > + struct task_struct *g, *task; > + unsigned int cpu; > + > + WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED); > + > + pr_notice("'%s': %s...\n", klp_transition_patch->mod->name, > +

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > +void klp_start_transition(void) > +{ > + struct task_struct *g, *task; > + unsigned int cpu; > + > + WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED); > + > + pr_notice("'%s': %s...\n", klp_transition_patch->mod->name, > +

Re: [PATCH v3 12/15] livepatch: store function sizes

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > For the consistency model we'll need to know the sizes of the old and > new functions to determine if they're on the stacks of any tasks. > > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Acked-by: Miroslav Benes <mbe...@suse.cz> Miroslav

Re: [PATCH v3 12/15] livepatch: store function sizes

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > For the consistency model we'll need to know the sizes of the old and > new functions to determine if they're on the stacks of any tasks. > > Signed-off-by: Josh Poimboeuf Acked-by: Miroslav Benes Miroslav

Re: [PATCH v3 11/15] livepatch: use kstrtobool() in enabled_store()

toul(buf, 10, ); > > > + ret = kstrtobool(buf, ); > > > if (ret) > > > return -EINVAL; > > > > I would return "ret" here. It is -EINVAL as well but... ;-) > > That was a preexisting issue with the kstrtoul() return code, but I'll > sneak your suggested change into this patch if nobody objects. Fine with me. Acked-by: Miroslav Benes <mbe...@suse.cz> Miroslav

Re: [PATCH v3 08/15] livepatch: separate enabled and patched states

not necessarily > fully applied). > > - Patched means that an object's funcs are registered with ftrace and > added to the klp_ops func stack. > > Also, since these states are binary, represent them with booleans > instead of ints. > > Signed-off-by: Josh Poimboeuf <

Re: [PATCH v3 11/15] livepatch: use kstrtobool() in enabled_store()

l(buf, ); > > > if (ret) > > > return -EINVAL; > > > > I would return "ret" here. It is -EINVAL as well but... ;-) > > That was a preexisting issue with the kstrtoul() return code, but I'll > sneak your suggested change into this patch if nobody objects. Fine with me. Acked-by: Miroslav Benes Miroslav

Re: [PATCH v3 08/15] livepatch: separate enabled and patched states

not necessarily > fully applied). > > - Patched means that an object's funcs are registered with ftrace and > added to the klp_ops func stack. > > Also, since these states are binary, represent them with booleans > instead of ints. > > Signed-off-by: Josh Poimboeuf Acked-by: Miroslav Benes Miroslav

Re: [PATCH v3 10/15] livepatch: move patching functions into patch.c

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > Move functions related to the actual patching of functions and objects > into a new patch.c file. > > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Acked-by: Miroslav Benes <mbe...@suse.cz> Miroslav

Re: [PATCH v3 10/15] livepatch: move patching functions into patch.c

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > Move functions related to the actual patching of functions and objects > into a new patch.c file. > > Signed-off-by: Josh Poimboeuf Acked-by: Miroslav Benes Miroslav

Re: [PATCH v3 09/15] livepatch: remove unnecessary object loaded check

ff-by: Josh Poimboeuf <jpoim...@redhat.com> Acked-by: Miroslav Benes <mbe...@suse.cz> Miroslav

Re: [PATCH v3 09/15] livepatch: remove unnecessary object loaded check

ff-by: Josh Poimboeuf Acked-by: Miroslav Benes Miroslav

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

> > > diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c > > > index 5efa262..e79ebb5 100644 > > > --- a/kernel/livepatch/patch.c > > > +++ b/kernel/livepatch/patch.c > > > @@ -29,6 +29,7 @@ > > > #include > > > #include > > > #include "patch.h" > > > +#include "transition.h" >

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

> > > diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c > > > index 5efa262..e79ebb5 100644 > > > --- a/kernel/livepatch/patch.c > > > +++ b/kernel/livepatch/patch.c > > > @@ -29,6 +29,7 @@ > > > #include > > > #include > > > #include "patch.h" > > > +#include "transition.h" >

Re: [PATCH v3 06/15] livepatch/s390: reorganize TIF thread flag bits

<jpoim...@redhat.com> I believe there is no harm doing that and we need it for _TIF_PATCH_PENDING later. Reviewed-by: Miroslav Benes <mbe...@suse.cz> Miroslav

Re: [PATCH v3 06/15] livepatch/s390: reorganize TIF thread flag bits

oing that and we need it for _TIF_PATCH_PENDING later. Reviewed-by: Miroslav Benes Miroslav

Re: [PATCH v3 05/15] livepatch/powerpc: add TIF_PATCH_PENDING thread flag

> > The bit is included in the _TIF_USER_WORK_MASK macro so that > do_notify_resume() and klp_update_patch_state() get called when the bit > is set. > > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Looks good to me. You can add my Reviewed-by: Miroslav Benes <mbe...@suse.cz> Miroslav

Re: [PATCH v3 05/15] livepatch/powerpc: add TIF_PATCH_PENDING thread flag

> > The bit is included in the _TIF_USER_WORK_MASK macro so that > do_notify_resume() and klp_update_patch_state() get called when the bit > is set. > > Signed-off-by: Josh Poimboeuf Looks good to me. You can add my Reviewed-by: Miroslav Benes Miroslav

Re: [PATCH v3 04/15] livepatch/x86: add TIF_PATCH_PENDING thread flag

> > The bit is placed in the _TIF_ALLWORK_MASK macro, which results in > exit_to_usermode_loop() calling klp_update_patch_state() when it's set. > > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Reviewed-by: Miroslav Benes <mbe...@suse.cz> Miroslav

Re: [PATCH v3 04/15] livepatch/x86: add TIF_PATCH_PENDING thread flag

> > The bit is placed in the _TIF_ALLWORK_MASK macro, which results in > exit_to_usermode_loop() calling klp_update_patch_state() when it's set. > > Signed-off-by: Josh Poimboeuf Reviewed-by: Miroslav Benes Miroslav

Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Mon, 19 Dec 2016, Josh Poimboeuf wrote: > On Mon, Dec 19, 2016 at 05:25:19PM +0100, Miroslav Benes wrote: > > On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > index 215612c..b4a6663 100644 > > &g

Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Mon, 19 Dec 2016, Josh Poimboeuf wrote: > On Mon, Dec 19, 2016 at 05:25:19PM +0100, Miroslav Benes wrote: > > On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > index 215612c..b4a6663 100644 > > &g

Re: [PATCH v3 02/15] x86/entry: define _TIF_ALLWORK_MASK flags explicitly

ne the flags explicitly. > > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> With _TIF_SINGLESTEP and _TIF_NEED_RESCHED swapped you can add my Reviewed-by: Miroslav Benes <mbe...@suse.cz> Miroslav > --- > arch/x86/include/asm/thread_info.h | 9 - > 1 fil

Re: [PATCH v3 02/15] x86/entry: define _TIF_ALLWORK_MASK flags explicitly

ne the flags explicitly. > > Signed-off-by: Josh Poimboeuf With _TIF_SINGLESTEP and _TIF_NEED_RESCHED swapped you can add my Reviewed-by: Miroslav Benes Miroslav > --- > arch/x86/include/asm/thread_info.h | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > >

Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 215612c..b4a6663 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -155,6 +155,7 @@ config X86 > select HAVE_PERF_REGS > select HAVE_PERF_USER_STACK_DUMP > select

Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 215612c..b4a6663 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -155,6 +155,7 @@ config X86 > select HAVE_PERF_REGS > select HAVE_PERF_USER_STACK_DUMP > select

Re: [PATCH] livepatch: fixup klp-convert tool integration

On Sat, 17 Dec 2016, Konstantin Khlebnikov wrote: > I've found some minor problems, this patch fixes: > > * save cmd_ld_ko_o into .module.cmd, if_changed_rule doesn't do that > * fix bashisms for debian where /bin/sh is a symlink to /bin/dash > * rename rule_link_module to rule_ld_ko_o,

Re: [PATCH] livepatch: fixup klp-convert tool integration

On Sat, 17 Dec 2016, Konstantin Khlebnikov wrote: > I've found some minor problems, this patch fixes: > > * save cmd_ld_ko_o into .module.cmd, if_changed_rule doesn't do that > * fix bashisms for debian where /bin/sh is a symlink to /bin/dash > * rename rule_link_module to rule_ld_ko_o,

Re: [RFC 02/10] module: fix memory leak on early load_module() failures

[] process_one_work+0x1f3/0x4b0 > [] worker_thread+0x48/0x4e0 > [] kthread+0xc9/0xe0 > [] ret_from_fork+0x1f/0x40 > [] 0x > > Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> Reviewed-by: Miroslav Benes <mbe...@suse.cz> What abo

Re: [RFC 02/10] module: fix memory leak on early load_module() failures

[] process_one_work+0x1f3/0x4b0 > [] worker_thread+0x48/0x4e0 > [] kthread+0xc9/0xe0 > [] ret_from_fork+0x1f/0x40 > [] 0x > > Signed-off-by: Luis R. Rodriguez Reviewed-by: Miroslav Benes What about Fixes: e180a6b7759a ("param: fix char

Re: [PATCH v2] infiniband: remove WARN that is not kernel bug

On Mon, 21 Nov 2016, Dmitry Vyukov wrote: > WARNINGs mean kernel bugs. > The one in ucma_write() points to user programming error > or a malicious attempt. This is not a kernel bug, remove it. > > BUG/WARNs that are not kernel bugs hinder automated testing effots. > > Signed-off-by: Dmitry

Re: [PATCH v2] infiniband: remove WARN that is not kernel bug

On Mon, 21 Nov 2016, Dmitry Vyukov wrote: > WARNINGs mean kernel bugs. > The one in ucma_write() points to user programming error > or a malicious attempt. This is not a kernel bug, remove it. > > BUG/WARNs that are not kernel bugs hinder automated testing effots. > > Signed-off-by: Dmitry

Re: module: Ensure a module's state is set accordingly during module coming cleanup code

ill also correctly fail for GOING > modules in the module_is_live() check in the subsequent call to > try_module_get(), so I believe we are still OK here. FWIW, I looked and this is true. Even the error -ENOENT could be better in this case than -EBUSY (since the module is going away). Rev

Re: module: Ensure a module's state is set accordingly during module coming cleanup code

ectly fail for GOING > modules in the module_is_live() check in the subsequent call to > try_module_get(), so I believe we are still OK here. FWIW, I looked and this is true. Even the error -ENOENT could be better in this case than -EBUSY (since the module is going away). Reviewed-by: Miroslav Benes

Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal

On Thu, 10 Nov 2016, Miroslav Benes wrote: > On Thu, 10 Nov 2016, Josh Poimboeuf wrote: > > > Does anybody want to take ownership of this patch set and/or try to > > explore the options further? I don't have any more bandwidth right now > > (mainly due to the consi

Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal

On Thu, 10 Nov 2016, Miroslav Benes wrote: > On Thu, 10 Nov 2016, Josh Poimboeuf wrote: > > > Does anybody want to take ownership of this patch set and/or try to > > explore the options further? I don't have any more bandwidth right now > > (mainly due to the consi

Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal

On Thu, 10 Nov 2016, Josh Poimboeuf wrote: > On Thu, Oct 27, 2016 at 09:35:48AM -0500, Josh Poimboeuf wrote: > > So here's my proposal: use the existing kernel build infrastructure. If > > klp relocations are needed, manually specify them with a new > > klp_module_reloc struct and corresponding

Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal

On Thu, 10 Nov 2016, Josh Poimboeuf wrote: > On Thu, Oct 27, 2016 at 09:35:48AM -0500, Josh Poimboeuf wrote: > > So here's my proposal: use the existing kernel build infrastructure. If > > klp relocations are needed, manually specify them with a new > > klp_module_reloc struct and corresponding

Re: [PATCH v2] livepatch/module: make TAINT_LIVEPATCH module-specific

h...@redhat.com> > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Acked-by: Miroslav Benes <mbe...@suse.cz> Miroslav

Re: [PATCH v2] livepatch/module: make TAINT_LIVEPATCH module-specific

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

Re: [PATCH] livepatch/module: make TAINT_LIVEPATCH module-specific

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_LIVEPATCH.

Re: [PATCH] livepatch/module: make TAINT_LIVEPATCH module-specific

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_LIVEPATCH.

Re: [PATCH] livepatch/module: make TAINT_LIVEPATCH module-specific

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

Re: [PATCH] livepatch/module: make TAINT_LIVEPATCH module-specific

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

Re: [PATCH v3 0/3] Fix issue with alternatives/paravirt patches

ch, we don't support including jump table sections in > the patch module, and supporting .smp_locks is currently broken, so we > don't consider those sections (for now). > > I did some light testing with some patches to kvm and verified that the > original issue reported in [2] was fixed

Re: [PATCH v3 0/3] Fix issue with alternatives/paravirt patches

ch, we don't support including jump table sections in > the patch module, and supporting .smp_locks is currently broken, so we > don't consider those sections (for now). > > I did some light testing with some patches to kvm and verified that the > original issue reported in [2] was fixed. > > Based on linux-next. For the whole patch set Acked-by: Miroslav Benes Thanks Miroslav

Re: [PATCH] arm64: take SHN_LIVEPATCH syms into account when calculating plt_max_entries

On Tue, 12 Jul 2016, Jessica Yu wrote: > SHN_LIVEPATCH symbols are technically a subset of SHN_UNDEF/undefined > symbols, except that their addresses are resolved by livepatch at runtime. > Therefore, when calculating the upper-bound for the number of plt entries > to allocate, make sure to take

Re: [PATCH] arm64: take SHN_LIVEPATCH syms into account when calculating plt_max_entries

On Tue, 12 Jul 2016, Jessica Yu wrote: > SHN_LIVEPATCH symbols are technically a subset of SHN_UNDEF/undefined > symbols, except that their addresses are resolved by livepatch at runtime. > Therefore, when calculating the upper-bound for the number of plt entries > to allocate, make sure to take

Re: A bug in ftrace - dynamic fops

On Thu, 11 Aug 2016, Steven Rostedt wrote: > On Thu, 11 Aug 2016 16:08:58 +0200 (CEST) > Miroslav Benes <mbe...@suse.cz> wrote: > > > /* > > * Dynamic ops may be freed, we must make sure that all > > * callers are

Re: A bug in ftrace - dynamic fops

On Thu, 11 Aug 2016, Steven Rostedt wrote: > On Thu, 11 Aug 2016 16:08:58 +0200 (CEST) > Miroslav Benes wrote: > > > /* > > * Dynamic ops may be freed, we must make sure that all > > * callers are done before leaving this function. &

Re: A bug in ftrace - dynamic fops

On Thu, 11 Aug 2016, Steven Rostedt wrote: > On Thu, 11 Aug 2016 10:46:53 +0200 (CEST) > Miroslav Benes <mbe...@suse.cz> wrote: > > > On Tue, 9 Aug 2016, Steven Rostedt wrote: > > > > > On Tue, 9 Aug 2016 10:16:00 +0200 (CEST) > &g

Re: A bug in ftrace - dynamic fops

On Thu, 11 Aug 2016, Steven Rostedt wrote: > On Thu, 11 Aug 2016 10:46:53 +0200 (CEST) > Miroslav Benes wrote: > > > On Tue, 9 Aug 2016, Steven Rostedt wrote: > > > > > On Tue, 9 Aug 2016 10:16:00 +0200 (CEST) > > > Miroslav Benes wrote: > > >

Re: A bug in ftrace - dynamic fops

On Tue, 9 Aug 2016, Steven Rostedt wrote: > On Tue, 9 Aug 2016 10:16:00 +0200 (CEST) > Miroslav Benes <mbe...@suse.cz> wrote: > > > > I agree it is kind of shooting oneself in the foot bug, because explicit > > call to a sleeping function may not be the brighte

Re: A bug in ftrace - dynamic fops

On Tue, 9 Aug 2016, Steven Rostedt wrote: > On Tue, 9 Aug 2016 10:16:00 +0200 (CEST) > Miroslav Benes wrote: > > > > I agree it is kind of shooting oneself in the foot bug, because explicit > > call to a sleeping function may not be the brightest thing to do. However

Re: A bug in ftrace - dynamic fops

On Mon, 8 Aug 2016, Steven Rostedt wrote: > On Mon, 8 Aug 2016 10:57:45 +0200 (CEST) > Miroslav Benes <mbe...@suse.cz> wrote: > > > Hi Steven, > > > > I am afraid there is a bug in the current mainline's ftrace when dynamic > > fops are i

Re: A bug in ftrace - dynamic fops

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 sorry but I do

A bug in ftrace - dynamic fops

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

A bug in ftrace - dynamic fops

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

Re: [PATCH v2 2/2] livepatch/x86: apply alternatives and paravirt patches after relocations

On Thu, 21 Jul 2016, Jessica Yu wrote: > Implement arch_klp_init_object_loaded() for x86, which applies > alternatives/paravirt patches. This fixes the order in which relocations > and alternatives/paravirt patches are applied. > > Previously, if a patch module had alternatives or paravirt

Re: [PATCH v2 2/2] livepatch/x86: apply alternatives and paravirt patches after relocations

On Thu, 21 Jul 2016, Jessica Yu wrote: > Implement arch_klp_init_object_loaded() for x86, which applies > alternatives/paravirt patches. This fixes the order in which relocations > and alternatives/paravirt patches are applied. > > Previously, if a patch module had alternatives or paravirt

Re: [PATCH v2 1/2] livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks

On Thu, 21 Jul 2016, Jessica Yu wrote: > Introduce arch_klp_init_object_loaded() to complete any additional > arch-specific tasks during patching. Architecture code may override this > function. > > Signed-off-by: Jessica Yu > --- > include/linux/livepatch.h | 3 +++ >

Re: [PATCH v2 1/2] livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks

On Thu, 21 Jul 2016, Jessica Yu wrote: > Introduce arch_klp_init_object_loaded() to complete any additional > arch-specific tasks during patching. Architecture code may override this > function. > > Signed-off-by: Jessica Yu > --- > include/linux/livepatch.h | 3 +++ > kernel/livepatch/core.c

Re: Fix issue with alternatives/paravirt patches

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

Re: Fix issue with alternatives/paravirt patches

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

Re: [PATCH 0/2] Fix issue with alternatives/paravirt patches

On Tue, 5 Jul 2016, Jessica Yu wrote: > Hi, > > A few months ago, Chris Arges reported a bug involving alternatives/paravirt > patching that was discussed here [1] and here [2]. To briefly summarize the > bug, patch modules that contained .altinstructions or .parainstructions > sections would

Re: [PATCH 0/2] Fix issue with alternatives/paravirt patches

On Tue, 5 Jul 2016, Jessica Yu wrote: > Hi, > > A few months ago, Chris Arges reported a bug involving alternatives/paravirt > patching that was discussed here [1] and here [2]. To briefly summarize the > bug, patch modules that contained .altinstructions or .parainstructions > sections would

Re: [PATCH 0/2] Fix issue with alternatives/paravirt patches

On Thu, 7 Jul 2016, Josh Poimboeuf wrote: > On Thu, Jul 07, 2016 at 05:56:33PM +0200, Petr Mladek wrote: > > On Tue 2016-07-05 22:34:58, Jessica Yu wrote: > > > Hi, > > > > > > A few months ago, Chris Arges reported a bug involving > > > alternatives/paravirt > > > patching that was discussed

Re: [PATCH 0/2] Fix issue with alternatives/paravirt patches

On Thu, 7 Jul 2016, Josh Poimboeuf wrote: > On Thu, Jul 07, 2016 at 05:56:33PM +0200, Petr Mladek wrote: > > On Tue 2016-07-05 22:34:58, Jessica Yu wrote: > > > Hi, > > > > > > A few months ago, Chris Arges reported a bug involving > > > alternatives/paravirt > > > patching that was discussed

Re: arm64: implement live patching

On Mon, 11 Jul 2016, Jessica Yu wrote: > +++ Miroslav Benes [11/07/16 16:03 +0200]: > > On Mon, 27 Jun 2016, Torsten Duwe wrote: > > > > > diff --git a/arch/arm64/include/asm/livepatch.h > > > b/arch/arm64/include/asm/livepatch.h > > > new fil

Re: arm64: implement live patching

On Mon, 11 Jul 2016, Jessica Yu wrote: > +++ Miroslav Benes [11/07/16 16:03 +0200]: > > On Mon, 27 Jun 2016, Torsten Duwe wrote: > > > > > diff --git a/arch/arm64/include/asm/livepatch.h > > > b/arch/arm64/include/asm/livepatch.h > > > new fil

Re: [PATCH v2 2/2] arm64: implement live patching

On Mon, 27 Jun 2016, Torsten Duwe wrote: > diff --git a/arch/arm64/include/asm/livepatch.h > b/arch/arm64/include/asm/livepatch.h > new file mode 100644 > index 000..6b9a3d1 > --- /dev/null > +++ b/arch/arm64/include/asm/livepatch.h > @@ -0,0 +1,37 @@ > +/* > + * livepatch.h - arm64-specific

Re: [PATCH v2 2/2] arm64: implement live patching

On Mon, 27 Jun 2016, Torsten Duwe wrote: > diff --git a/arch/arm64/include/asm/livepatch.h > b/arch/arm64/include/asm/livepatch.h > new file mode 100644 > index 000..6b9a3d1 > --- /dev/null > +++ b/arch/arm64/include/asm/livepatch.h > @@ -0,0 +1,37 @@ > +/* > + * livepatch.h - arm64-specific

Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

Hi, On Wed, 22 Jun 2016, Josh Poimboeuf wrote: > On Wed, Jun 22, 2016 at 04:24:41PM +0200, Torsten Duwe wrote: > > Live patching, as we use it, deliberately disrupts the fabric of > > compile units; thus all assumptions a compiler can make about the > > control flow may be invalid. As an

Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

Hi, On Wed, 22 Jun 2016, Josh Poimboeuf wrote: > On Wed, Jun 22, 2016 at 04:24:41PM +0200, Torsten Duwe wrote: > > Live patching, as we use it, deliberately disrupts the fabric of > > compile units; thus all assumptions a compiler can make about the > > control flow may be invalid. As an

Re: [PATCH v2] livepatch: allow removal of a disabled patch

On Wed, 1 Jun 2016, Christopher Arges wrote: > On Wed, Jun 01, 2016 at 10:31:59AM +0200, Miroslav Benes wrote: > > > > diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c > > index 92819bb0961b..6cc49d253195 100644 > > --- a/kernel/livepatch/tr

Re: [PATCH v2] livepatch: allow removal of a disabled patch

On Wed, 1 Jun 2016, Christopher Arges wrote: > On Wed, Jun 01, 2016 at 10:31:59AM +0200, Miroslav Benes wrote: > > > > diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c > > index 92819bb0961b..6cc49d253195 100644 > > --- a/kernel/livepatch/tr

[PATCH v2] livepatch: allow removal of a disabled patch

have their sysfs counterparts. Signed-off-by: Miroslav Benes <mbe...@suse.cz> --- Based on Josh's v2 of the consistency model. Documentation/livepatch/livepatch.txt | 29 - include/linux/livepatch.h | 3 ++ kernel/livepatch/cor

[PATCH v2] livepatch: allow removal of a disabled patch

have their sysfs counterparts. Signed-off-by: Miroslav Benes --- Based on Josh's v2 of the consistency model. Documentation/livepatch/livepatch.txt | 29 - include/linux/livepatch.h | 3 ++ kernel/livepatch/core.c | 80 ++-

Re: livepatch: Avoid possible race when releasing the patch

On Mon, 23 May 2016, Jessica Yu wrote: > +++ Petr Mladek [23/05/16 17:54 +0200]: > > There was a long discussion about a possible race with sysfs, kobjects > > when removing an unused livepatch, see > > https://lkml.kernel.org/g/%3c1462190242-24731-1-git-send-email-mbe...@suse.cz%3E > > > > This

Re: livepatch: Avoid possible race when releasing the patch

On Mon, 23 May 2016, Jessica Yu wrote: > +++ Petr Mladek [23/05/16 17:54 +0200]: > > There was a long discussion about a possible race with sysfs, kobjects > > when removing an unused livepatch, see > > https://lkml.kernel.org/g/%3c1462190242-24731-1-git-send-email-mbe...@suse.cz%3E > > > > This

Re: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Thu, 28 Apr 2016, Josh Poimboeuf wrote: > Change livepatch to use a basic per-task consistency model. This is the > foundation which will eventually enable us to patch those ~10% of > security patches which change function or data semantics. This is the > biggest remaining piece needed to

Re: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Thu, 28 Apr 2016, Josh Poimboeuf wrote: > Change livepatch to use a basic per-task consistency model. This is the > foundation which will eventually enable us to patch those ~10% of > security patches which change function or data semantics. This is the > biggest remaining piece needed to

Re: barriers: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Wed, 4 May 2016, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 04:12:05PM +0200, Petr Mladek wrote: > > On Wed 2016-05-04 14:39:40, Petr Mladek wrote: > > >* > > >* Note that the task must never be migrated to the target > > >* state when being inside this

Re: barriers: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Wed, 4 May 2016, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 04:12:05PM +0200, Petr Mladek wrote: > > On Wed 2016-05-04 14:39:40, Petr Mladek wrote: > > >* > > >* Note that the task must never be migrated to the target > > >* state when being inside this

Re: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

[...] > +static int klp_target_state; [...] > +void klp_init_transition(struct klp_patch *patch, int state) > +{ > + struct task_struct *g, *task; > + unsigned int cpu; > + struct klp_object *obj; > + struct klp_func *func; > + int initial_state = !state; > + > +

Re: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

[...] > +static int klp_target_state; [...] > +void klp_init_transition(struct klp_patch *patch, int state) > +{ > + struct task_struct *g, *task; > + unsigned int cpu; > + struct klp_object *obj; > + struct klp_func *func; > + int initial_state = !state; > + > +

<    4   5   6   7   8   9   10   11   12   13   >