Re: livepatch: allow removal of a disabled patch

On Thu, 5 May 2016, Jessica Yu wrote: > +++ Josh Poimboeuf [05/05/16 10:04 -0500]: > > On Thu, May 05, 2016 at 04:25:48PM +0200, Miroslav Benes wrote: > > > On Thu, 5 May 2016, Josh Poimboeuf wrote: > > > > > > > On Thu, May 05, 2016 at 10:28:12AM +0200,

Re: livepatch: allow removal of a disabled patch

On Thu, 5 May 2016, Jessica Yu wrote: > +++ Josh Poimboeuf [05/05/16 10:04 -0500]: > > On Thu, May 05, 2016 at 04:25:48PM +0200, Miroslav Benes wrote: > > > On Thu, 5 May 2016, Josh Poimboeuf wrote: > > > > > > > On Thu, May 05, 2016 at 10:28:12AM +0200,

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

On Thu, 5 May 2016, Josh Poimboeuf wrote: > On Thu, May 05, 2016 at 10:28:12AM +0200, Miroslav Benes wrote: > > I think it boils down to the following problem. > > > > 1. CONFIG_DEBUG_KOBJECT_RELEASE=y > > > > 2. we have dynamic kobjects, so there is

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

On Thu, 5 May 2016, Josh Poimboeuf wrote: > On Thu, May 05, 2016 at 10:28:12AM +0200, Miroslav Benes wrote: > > I think it boils down to the following problem. > > > > 1. CONFIG_DEBUG_KOBJECT_RELEASE=y > > > > 2. we have dynamic kobjects, so there is

Re: [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 10:42:23AM +0200, Petr Mladek wrote: > > On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote: > > > Change livepatch to use a basic per-task consistency model. This is the > > > foundation which will eventually enable us to patch

Re: [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 10:42:23AM +0200, Petr Mladek wrote: > > On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote: > > > Change livepatch to use a basic per-task consistency model. This is the > > > foundation which will eventually enable us to patch

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

On Wed, 4 May 2016, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 04:35:28PM +0200, Miroslav Benes wrote: > > On Wed, 4 May 2016, Josh Poimboeuf wrote: > > > > > On Wed, May 04, 2016 at 01:58:47PM +0200, Miroslav Benes wrote: > > > > On T

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

On Wed, 4 May 2016, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 04:35:28PM +0200, Miroslav Benes wrote: > > On Wed, 4 May 2016, Josh Poimboeuf wrote: > > > > > On Wed, May 04, 2016 at 01:58:47PM +0200, Miroslav Benes wrote: > > > > On T

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

On Wed, 4 May 2016, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 01:58:47PM +0200, Miroslav Benes wrote: > > On Tue, 3 May 2016, Josh Poimboeuf wrote: > > > > > On Tue, May 03, 2016 at 09:39:48PM -0500, Josh Poimboeuf wrote: > > > > On Wed, May 04, 2016 at

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

On Wed, 4 May 2016, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 01:58:47PM +0200, Miroslav Benes wrote: > > On Tue, 3 May 2016, Josh Poimboeuf wrote: > > > > > On Tue, May 03, 2016 at 09:39:48PM -0500, Josh Poimboeuf wrote: > > > > On Wed, May 04, 2016 at

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

On Tue, 3 May 2016, Josh Poimboeuf wrote: > On Tue, May 03, 2016 at 09:39:48PM -0500, Josh Poimboeuf wrote: > > On Wed, May 04, 2016 at 12:31:12AM +0200, Jiri Kosina wrote: > > > On Tue, 3 May 2016, Josh Poimboeuf wrote: > > > > > > > > 1. Do we really need a completion? If I am not missing

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

On Tue, 3 May 2016, Josh Poimboeuf wrote: > On Tue, May 03, 2016 at 09:39:48PM -0500, Josh Poimboeuf wrote: > > On Wed, May 04, 2016 at 12:31:12AM +0200, Jiri Kosina wrote: > > > On Tue, 3 May 2016, Josh Poimboeuf wrote: > > > > > > > > 1. Do we really need a completion? If I am not missing

Re: [RFC PATCH v2 10/18] livepatch/powerpc: add TIF_PATCH_PENDING thread flag

On Tue, 3 May 2016, Petr Mladek wrote: > On Thu 2016-04-28 15:44:41, Josh Poimboeuf wrote: > > Add the TIF_PATCH_PENDING thread flag to enable the new livepatch > > per-task consistency model for powerpc. The bit getting set indicates > > the thread has a pending patch which needs to be applied

Re: [RFC PATCH v2 10/18] livepatch/powerpc: add TIF_PATCH_PENDING thread flag

On Tue, 3 May 2016, Petr Mladek wrote: > On Thu 2016-04-28 15:44:41, Josh Poimboeuf wrote: > > Add the TIF_PATCH_PENDING thread flag to enable the new livepatch > > per-task consistency model for powerpc. The bit getting set indicates > > the thread has a pending patch which needs to be applied

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

On Mon, 2 May 2016, Josh Poimboeuf wrote: > On Mon, May 02, 2016 at 01:57:22PM +0200, Miroslav Benes wrote: > > Currently we do not allow patch module to unload since there is no > > method to determine if a task is still running in the patched code. > > > > The

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

On Mon, 2 May 2016, Josh Poimboeuf wrote: > On Mon, May 02, 2016 at 01:57:22PM +0200, Miroslav Benes wrote: > > Currently we do not allow patch module to unload since there is no > > method to determine if a task is still running in the patched code. > > > > The

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

her kobject_put() callsites as we currently do not have their sysfs counterparts. Signed-off-by: Miroslav Benes <mbe...@suse.cz> --- Based on Josh's v2. There are still two things which need to be discussed. 1. Do we really need a completion? If I am not missing something kobject_del() alw

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

her kobject_put() callsites as we currently do not have their sysfs counterparts. Signed-off-by: Miroslav Benes --- Based on Josh's v2. There are still two things which need to be discussed. 1. Do we really need a completion? If I am not missing something kobject_del() always waits for sysfs call

Re: klp: make object/func-walking helpers more robust

On Thu, 28 Apr 2016, Josh Poimboeuf wrote: > On Thu, Apr 28, 2016 at 02:21:31PM -0400, Jessica Yu wrote: > > +++ Miroslav Benes [28/04/16 16:34 +0200]: > > > Current object-walking helper checks the presence of obj->funcs to > > > determine the end of objs

Re: klp: make object/func-walking helpers more robust

On Thu, 28 Apr 2016, Josh Poimboeuf wrote: > On Thu, Apr 28, 2016 at 02:21:31PM -0400, Jessica Yu wrote: > > +++ Miroslav Benes [28/04/16 16:34 +0200]: > > > Current object-walking helper checks the presence of obj->funcs to > > > determine the end of objs

[PATCH] klp: make object/func-walking helpers more robust

t work. The same applies to a func-walking helper. As a benefit we'll check for new_func member definition during the livepatch initialization. There is no such check anywhere in the code now. Signed-off-by: Miroslav Benes <mbe...@suse.cz> --- include/linux/livepatch.h | 6 -- kernel/livepatch/

[PATCH] klp: make object/func-walking helpers more robust

t work. The same applies to a func-walking helper. As a benefit we'll check for new_func member definition during the livepatch initialization. There is no such check anywhere in the code now. Signed-off-by: Miroslav Benes --- include/linux/livepatch.h | 6 -- kernel/livepatch/core.c | 3 +++ 2

Re: [PATCH v2] livepatch: Add some basic LivePatch documentation

On Tue, 26 Apr 2016, Balbir Singh wrote: > > + + Anything inlined into __schedule() can not be patched. > > + > > +The switch_to macro is inlined into __schedule(). It switches the > > +context between two processes in the middle of the macro. It does > > +not save RIP in x86_64

Re: [PATCH v2] livepatch: Add some basic LivePatch documentation

On Tue, 26 Apr 2016, Balbir Singh wrote: > > + + Anything inlined into __schedule() can not be patched. > > + > > +The switch_to macro is inlined into __schedule(). It switches the > > +context between two processes in the middle of the macro. It does > > +not save RIP in x86_64

[RFC PATCH 1/2] s390: livepatch, reorganize TIF bits

From: Jiri Slaby Signed-off-by: Jiri Slaby --- arch/s390/include/asm/thread_info.h | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/arch/s390/include/asm/thread_info.h b/arch/s390/include/asm/thread_info.h index

[RFC PATCH 1/2] s390: livepatch, reorganize TIF bits

From: Jiri Slaby Signed-off-by: Jiri Slaby --- arch/s390/include/asm/thread_info.h | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/arch/s390/include/asm/thread_info.h b/arch/s390/include/asm/thread_info.h index 2fffc2c27581..8642c1dab382 100644 ---

[RFC PATCH 0/2] s390/klp: s390 support

? Comments are obviously welcome. s390 maintainters not CC'ed yet. Jiri Slaby (1): s390: livepatch, reorganize TIF bits Miroslav Benes (1): s390/klp: update task universe when exiting kernel arch/s390/include/asm/thread_info.h | 24 arch/s390/kernel/entry.S| 31

[RFC PATCH 0/2] s390/klp: s390 support

? Comments are obviously welcome. s390 maintainters not CC'ed yet. Jiri Slaby (1): s390: livepatch, reorganize TIF bits Miroslav Benes (1): s390/klp: update task universe when exiting kernel arch/s390/include/asm/thread_info.h | 24 arch/s390/kernel/entry.S| 31

[RFC PATCH 2/2] s390/klp: update task universe when exiting kernel

migrated in all return paths from a syscall. Signed-off-by: Miroslav Benes <mbe...@suse.cz> --- arch/s390/include/asm/thread_info.h | 2 ++ arch/s390/kernel/entry.S| 31 ++- 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/arch/s390/inclu

[RFC PATCH 2/2] s390/klp: update task universe when exiting kernel

migrated in all return paths from a syscall. Signed-off-by: Miroslav Benes --- arch/s390/include/asm/thread_info.h | 2 ++ arch/s390/kernel/entry.S| 31 ++- 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/arch/s390/include/asm/thread_info.h b

Re: [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model

On Thu, 14 Apr 2016, Josh Poimboeuf wrote: > On Thu, Apr 14, 2016 at 11:25:18AM +0200, Miroslav Benes wrote: > > On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > > > > > +/* > > > + * klp_update_task_universe() - change the patched state of a task > >

Re: [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model

On Thu, 14 Apr 2016, Josh Poimboeuf wrote: > On Thu, Apr 14, 2016 at 11:25:18AM +0200, Miroslav Benes wrote: > > On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > > > > > +/* > > > + * klp_update_task_universe() - change the patched state of a task > >

Re: Live patching for powerpc

On Thu, 14 Apr 2016, Jessica Yu wrote: > +++ Miroslav Benes [14/04/16 15:28 +0200]: > > On Wed, 13 Apr 2016, Jessica Yu wrote: > > > > A second concern I have is that apply_relocate_add() relies on > > > sections like .stubs and .toc (for 64-bit) and .init.plt and .

Re: Live patching for powerpc

On Thu, 14 Apr 2016, Jessica Yu wrote: > +++ Miroslav Benes [14/04/16 15:28 +0200]: > > On Wed, 13 Apr 2016, Jessica Yu wrote: > > > > A second concern I have is that apply_relocate_add() relies on > > > sections like .stubs and .toc (for 64-bit) and .init.plt and .

Re: [PATCH 2/5] livepatch: Allow architectures to specify an alternate ftrace location

On Thu, 14 Apr 2016, Michael Ellerman wrote: > On Thu, 2016-04-14 at 14:01 +0200, Miroslav Benes wrote: > > On Wed, 13 Apr 2016, Michael Ellerman wrote: > > > > static void klp_disable_func(struct klp_func *func) > > > { > > > struct klp_ops *ops;

Re: [PATCH 2/5] livepatch: Allow architectures to specify an alternate ftrace location

On Thu, 14 Apr 2016, Michael Ellerman wrote: > On Thu, 2016-04-14 at 14:01 +0200, Miroslav Benes wrote: > > On Wed, 13 Apr 2016, Michael Ellerman wrote: > > > > static void klp_disable_func(struct klp_func *func) > > > { > > > struct klp_ops *ops;

Re: Live patching for powerpc

On Wed, 13 Apr 2016, Jessica Yu wrote: > +++ Miroslav Benes [13/04/16 15:01 +0200]: > > On Wed, 13 Apr 2016, Michael Ellerman wrote: > > > > > This series adds live patching support for powerpc (ppc64le only ATM). > > > > > > It's unchan

Re: Live patching for powerpc

On Wed, 13 Apr 2016, Jessica Yu wrote: > +++ Miroslav Benes [13/04/16 15:01 +0200]: > > On Wed, 13 Apr 2016, Michael Ellerman wrote: > > > > > This series adds live patching support for powerpc (ppc64le only ATM). > > > > > > It's unchan

Re: [PATCH 3/5] powerpc/livepatch: Add livepatch header

On Thu, 14 Apr 2016, Miroslav Benes wrote: > On Wed, 13 Apr 2016, Michael Ellerman wrote: > > > Add the powerpc specific livepatch definitions. In particular we provide > > a non-default implementation of klp_get_ftrace_location(). > > > > This is required beca

Re: [PATCH 3/5] powerpc/livepatch: Add livepatch header

On Thu, 14 Apr 2016, Miroslav Benes wrote: > On Wed, 13 Apr 2016, Michael Ellerman wrote: > > > Add the powerpc specific livepatch definitions. In particular we provide > > a non-default implementation of klp_get_ftrace_location(). > > > > This is required beca

Re: [PATCH 3/5] powerpc/livepatch: Add livepatch header

On Wed, 13 Apr 2016, Michael Ellerman wrote: > Add the powerpc specific livepatch definitions. In particular we provide > a non-default implementation of klp_get_ftrace_location(). > > This is required because the location of the mcount call is not constant > when using -mprofile-kernel (which

Re: [PATCH 3/5] powerpc/livepatch: Add livepatch header

On Wed, 13 Apr 2016, Michael Ellerman wrote: > Add the powerpc specific livepatch definitions. In particular we provide > a non-default implementation of klp_get_ftrace_location(). > > This is required because the location of the mcount call is not constant > when using -mprofile-kernel (which

Re: [PATCH 2/5] livepatch: Allow architectures to specify an alternate ftrace location

On Wed, 13 Apr 2016, Michael Ellerman wrote: > When livepatch tries to patch a function it takes the function address > and asks ftrace to install the livepatch handler at that location. > ftrace will look for an mcount call site at that exact address. > > On powerpc the mcount location is not

Re: [PATCH 2/5] livepatch: Allow architectures to specify an alternate ftrace location

On Wed, 13 Apr 2016, Michael Ellerman wrote: > When livepatch tries to patch a function it takes the function address > and asks ftrace to install the livepatch handler at that location. > ftrace will look for an mcount call site at that exact address. > > On powerpc the mcount location is not

Re: [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model

On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > Add 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 prototypes and/or data semantics. > > When a patch is enabled, livepatch enters into a

Re: [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model

On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > Add 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 prototypes and/or data semantics. > > When a patch is enabled, livepatch enters into a

Re: [RFC PATCH v1.9 14/14] livepatch: update task universe when exiting kernel

On Thu, 14 Apr 2016, Miroslav Benes wrote: > On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > > > Update a tasks's universe when returning from a system call or user > > space interrupt, or after handling a signal. > > > > This greatly increases the chances o

Re: [RFC PATCH v1.9 14/14] livepatch: update task universe when exiting kernel

On Thu, 14 Apr 2016, Miroslav Benes wrote: > On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > > > Update a tasks's universe when returning from a system call or user > > space interrupt, or after handling a signal. > > > > This greatly increases the chances o

Re: [RFC PATCH v1.9 14/14] livepatch: update task universe when exiting kernel

On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > Update a tasks's universe when returning from a system call or user > space interrupt, or after handling a signal. > > This greatly increases the chances of a patch operation succeeding. If > a task is I/O bound, it can switch universes when

Re: [RFC PATCH v1.9 14/14] livepatch: update task universe when exiting kernel

On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > Update a tasks's universe when returning from a system call or user > space interrupt, or after handling a signal. > > This greatly increases the chances of a patch operation succeeding. If > a task is I/O bound, it can switch universes when

Re: [PATCH 0/5] Live patching for powerpc

On Wed, 13 Apr 2016, Michael Ellerman wrote: > This series adds live patching support for powerpc (ppc64le only ATM). > > It's unchanged since the version I posted on March 24, with the exception that > I've dropped the first patch, which was a testing-only patch. > > If there's no further

Re: [PATCH 0/5] Live patching for powerpc

On Wed, 13 Apr 2016, Michael Ellerman wrote: > This series adds live patching support for powerpc (ppc64le only ATM). > > It's unchanged since the version I posted on March 24, with the exception that > I've dropped the first patch, which was a testing-only patch. > > If there's no further

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Chris J Arges wrote: > On Wed, Apr 06, 2016 at 02:09:01PM +0200, Miroslav Benes wrote: > > On Wed, 6 Apr 2016, Chris J Arges wrote: > > > > > I think this approach needs more thought and my code has bug(s). > > > > And indeed there is...

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Chris J Arges wrote: > On Wed, Apr 06, 2016 at 02:09:01PM +0200, Miroslav Benes wrote: > > On Wed, 6 Apr 2016, Chris J Arges wrote: > > > > > I think this approach needs more thought and my code has bug(s). > > > > And indeed there is...

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Chris J Arges wrote: > I think this approach needs more thought and my code has bug(s). And indeed there is... long (*__kvm_arch_vm_ioctl)(struct file *filp, unsigned long ioctl, unsigned long arg) = NULL; Use a different name than __kvm_arch_vm_ioctl and (ideally) make it

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Chris J Arges wrote: > I think this approach needs more thought and my code has bug(s). And indeed there is... long (*__kvm_arch_vm_ioctl)(struct file *filp, unsigned long ioctl, unsigned long arg) = NULL; Use a different name than __kvm_arch_vm_ioctl and (ideally) make it

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Chris J Arges wrote: > On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote: > > On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > > > > > So I think this doesn't fix the problem. Dynamic relocations are > > > applied to the "patch

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Chris J Arges wrote: > On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote: > > On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > > > > > So I think this doesn't fix the problem. Dynamic relocations are > > > applied to the "patch

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Miroslav Benes wrote: > On Wed, 6 Apr 2016, Miroslav Benes wrote: > > > Anyway I see there are some new comments on github. I'll look at those. > > But I'd prefer to discuss all the relevant things (that is kpatch > > unspecific) here. It would make

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Miroslav Benes wrote: > On Wed, 6 Apr 2016, Miroslav Benes wrote: > > > Anyway I see there are some new comments on github. I'll look at those. > > But I'd prefer to discuss all the relevant things (that is kpatch > > unspecific) here. It would make

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Miroslav Benes wrote: > Anyway I see there are some new comments on github. I'll look at those. > But I'd prefer to discuss all the relevant things (that is kpatch > unspecific) here. It would make it easier. And you do (after seeing dates of the posts ther

Re: Bug with paravirt ops and livepatches

On Wed, 6 Apr 2016, Miroslav Benes wrote: > Anyway I see there are some new comments on github. I'll look at those. > But I'd prefer to discuss all the relevant things (that is kpatch > unspecific) here. It would make it easier. And you do (after seeing dates of the posts ther

Re: Bug with paravirt ops and livepatches

On Tue, 5 Apr 2016, Jessica Yu wrote: > +++ Miroslav Benes [05/04/16 15:07 +0200]: > > On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > > > > > So I think this doesn't fix the problem. Dynamic relocations are > > > applied to the "patch

Re: Bug with paravirt ops and livepatches

On Tue, 5 Apr 2016, Jessica Yu wrote: > +++ Miroslav Benes [05/04/16 15:07 +0200]: > > On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > > > > > So I think this doesn't fix the problem. Dynamic relocations are > > > applied to the "patch

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Tue, 5 Apr 2016, Josh Poimboeuf wrote: > On Tue, Apr 05, 2016 at 04:24:33PM +0200, Miroslav Benes wrote: > > On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > > > > > > I'd add a fake signal facility for sleeping non-migrated tasks. This > > > > would accel

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Tue, 5 Apr 2016, Josh Poimboeuf wrote: > On Tue, Apr 05, 2016 at 04:24:33PM +0200, Miroslav Benes wrote: > > On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > > > > > > I'd add a fake signal facility for sleeping non-migrated tasks. This > > > > would accel

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > > I'd add a fake signal facility for sleeping non-migrated tasks. This > > would accelerate a migration to a new universe. We have it in kgraft for > > quite some time and it worked out great. See > >

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > > I'd add a fake signal facility for sleeping non-migrated tasks. This > > would accelerate a migration to a new universe. We have it in kgraft for > > quite some time and it worked out great. See > >

Re: Bug with paravirt ops and livepatches

On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > So I think this doesn't fix the problem. Dynamic relocations are > applied to the "patch module", whereas the above code deals with the > initialization order of the "patched module". This distinction > originally confused me as well, until Jessica

Re: Bug with paravirt ops and livepatches

On Mon, 4 Apr 2016, Josh Poimboeuf wrote: > So I think this doesn't fix the problem. Dynamic relocations are > applied to the "patch module", whereas the above code deals with the > initialization order of the "patched module". This distinction > originally confused me as well, until Jessica

Re: Bug with paravirt ops and livepatches

On Fri, 1 Apr 2016, Jiri Kosina wrote: > On Tue, 29 Mar 2016, Jiri Kosina wrote: > > > Agreed; I think we should be safe applying all the alternatives (with > > paravirt being really just a special case of those) to the coming module > > at the very last phase; they really are required only

Re: Bug with paravirt ops and livepatches

On Fri, 1 Apr 2016, Jiri Kosina wrote: > On Tue, 29 Mar 2016, Jiri Kosina wrote: > > > Agreed; I think we should be safe applying all the alternatives (with > > paravirt being really just a special case of those) to the coming module > > at the very last phase; they really are required only

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

> - actually test it I did slightly and it partially worked and partially it did not. When I applied sample livepatch module, /proc/cmdline was patched and when I called 'cat /proc/cmdline' I got the correct livepatched message. So far so good. But the patching itself never finished because

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

> - actually test it I did slightly and it partially worked and partially it did not. When I applied sample livepatch module, /proc/cmdline was patched and when I called 'cat /proc/cmdline' I got the correct livepatched message. So far so good. But the patching itself never finished because

Re: [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model

On Fri, 25 Mar 2016, Josh Poimboeuf wrote: [...] > diff --git a/kernel/fork.c b/kernel/fork.c > index d277e83..27b181e 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -76,6 +76,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1615,6 +1616,7 @@

Re: [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model

On Fri, 25 Mar 2016, Josh Poimboeuf wrote: [...] > diff --git a/kernel/fork.c b/kernel/fork.c > index d277e83..27b181e 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -76,6 +76,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1615,6 +1616,7 @@

Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces

On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 2dc18605..76274b8 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -138,6 +138,7 @@ config X86 > select HAVE_PERF_REGS > select HAVE_PERF_USER_STACK_DUMP > select

Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces

On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 2dc18605..76274b8 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -138,6 +138,7 @@ config X86 > select HAVE_PERF_REGS > select HAVE_PERF_USER_STACK_DUMP > select

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

Hi, this is a great work. I'll have to review it properly (especially 13/14, probably several times as it is a heavy stuff), but I've gathered some notes so there they are. On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > These patches are still a work in progress, but Jiri asked that I share >

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

Hi, this is a great work. I'll have to review it properly (especially 13/14, probably several times as it is a heavy stuff), but I've gathered some notes so there they are. On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > These patches are still a work in progress, but Jiri asked that I share >

Re: Bug with paravirt ops and livepatches

[ adding CCs ] On Tue, 29 Mar 2016, Chris J Arges wrote: > Paravirtualized ops and livepatching currently don't mix very well and can > cause undefined behavor such as oops, invalid opcodes or corrupted stacks. > The original discussion of this issue can be found here [1]. > > I've written an

Re: Bug with paravirt ops and livepatches

[ adding CCs ] On Tue, 29 Mar 2016, Chris J Arges wrote: > Paravirtualized ops and livepatching currently don't mix very well and can > cause undefined behavor such as oops, invalid opcodes or corrupted stacks. > The original discussion of this issue can be found here [1]. > > I've written an

Re: [PATCH v6 0/5] (mostly) Arch-independent livepatch

On Tue, 22 Mar 2016, Jessica Yu wrote: > v6: > - Since we hard-code the field widths for the objname and symbol name >for the sscanf() calls, which are supposed to correspond to the values >of MODULE_NAME_LEN and KSYM_NAME_LEN, use BUILD_BUG_ON() to detect when >the values of these

Re: [PATCH v6 0/5] (mostly) Arch-independent livepatch

On Tue, 22 Mar 2016, Jessica Yu wrote: > v6: > - Since we hard-code the field widths for the objname and symbol name >for the sscanf() calls, which are supposed to correspond to the values >of MODULE_NAME_LEN and KSYM_NAME_LEN, use BUILD_BUG_ON() to detect when >the values of these

Re: [PATCH v5 5/6] samples: livepatch: mark as livepatch module

On Wed, 16 Mar 2016, Jessica Yu wrote: > Mark the module as a livepatch module so that the module loader can > appropriately identify and initialize it. > > Signed-off-by: Jessica Yu <j...@redhat.com> Reviewed-by: Miroslav Benes <mbe...@suse.cz>

Re: [PATCH v5 5/6] samples: livepatch: mark as livepatch module

On Wed, 16 Mar 2016, Jessica Yu wrote: > Mark the module as a livepatch module so that the module loader can > appropriately identify and initialize it. > > Signed-off-by: Jessica Yu Reviewed-by: Miroslav Benes

Re: [PATCH v5 6/6] Documentation: livepatch: outline Elf format and requirements for patch modules

On Wed, 16 Mar 2016, Jessica Yu wrote: > Document livepatch module requirements and the special Elf constants patch > modules use. > > Signed-off-by: Jessica Yu <j...@redhat.com> Fantastic to have it Acked-by: Miroslav Benes <mbe...@suse.cz>

Re: [PATCH v5 6/6] Documentation: livepatch: outline Elf format and requirements for patch modules

On Wed, 16 Mar 2016, Jessica Yu wrote: > Document livepatch module requirements and the special Elf constants patch > modules use. > > Signed-off-by: Jessica Yu Fantastic to have it Acked-by: Miroslav Benes

Re: [PATCH v5 4/6] livepatch: reuse module loader code to write relocations

- val + reloc->addend); > - if (ret) { > - pr_err("relocation failed for symbol '%s' at 0x%016lx > (%d)\n", > - reloc->name, val, ret); > - goto out; > + /* Check if this klp relocation section belongs to obj */ > + secname = pmod->klp_info->secstrings + sec->sh_name; > + cnt = sscanf(secname, ".klp.rela.%64[^.]", bufs.objname); Same here. Otherwise it looks really good (which applies for the whole series), so after fixing these nits you can add my Reviewed-by: Miroslav Benes <mbe...@suse.cz> Cheers, Miroslav

Re: [PATCH v5 4/6] livepatch: reuse module loader code to write relocations

- val + reloc->addend); > - if (ret) { > - pr_err("relocation failed for symbol '%s' at 0x%016lx > (%d)\n", > - reloc->name, val, ret); > - goto out; > + /* Check if this klp relocation section belongs to obj */ > + secname = pmod->klp_info->secstrings + sec->sh_name; > + cnt = sscanf(secname, ".klp.rela.%64[^.]", bufs.objname); Same here. Otherwise it looks really good (which applies for the whole series), so after fixing these nits you can add my Reviewed-by: Miroslav Benes Cheers, Miroslav

Re: [PATCH v5 3/6] module: s390: keep mod_arch_specific for livepatch modules

; Signed-off-by: Jessica Yu <j...@redhat.com> Reviewed-by: Miroslav Benes <mbe...@suse.cz>

Re: [PATCH v5 3/6] module: s390: keep mod_arch_specific for livepatch modules

-off-by: Jessica Yu Reviewed-by: Miroslav Benes

Re: [PATCH v5 2/6] module: preserve Elf information for livepatch modules

gt; symbol indices (and thus the symtab ordering) must be preserved in order > for apply_relocate_add() to find the right symbol. > > Signed-off-by: Jessica Yu <j...@redhat.com> With a fix for a bug reported by kbuild test robot Reviewed-by: Miroslav Benes <mbe...@suse.cz>

Re: [PATCH v5 2/6] module: preserve Elf information for livepatch modules

gt; symbol indices (and thus the symtab ordering) must be preserved in order > for apply_relocate_add() to find the right symbol. > > Signed-off-by: Jessica Yu With a fix for a bug reported by kbuild test robot Reviewed-by: Miroslav Benes

Re: [PATCH v5 1/6] Elf: add livepatch-specific Elf constants

e module loader ignores these symbols and does not attempt to resolve > them. > > The values of these Elf constants were selected from OS-specific > ranges according to the definitions from glibc. > > Signed-off-by: Jessica Yu <j...@redhat.com> Reviewed-by: Miroslav Benes <mbe...@suse.cz>

Re: [PATCH v5 1/6] Elf: add livepatch-specific Elf constants

e module loader ignores these symbols and does not attempt to resolve > them. > > The values of these Elf constants were selected from OS-specific > ranges according to the definitions from glibc. > > Signed-off-by: Jessica Yu Reviewed-by: Miroslav Benes

Re: [PATCH] livepatch: Update maintainers

ATCHING > M: Josh Poimboeuf <jpoim...@redhat.com> > -M: Seth Jennings <sjenn...@redhat.com> > +M: Jessica Yu <j...@redhat.com> > M: Jiri Kosina <ji...@kernel.org> > -M: Vojtech Pavlik <vojt...@suse.com> > +M: Miroslav Benes <mbe...@suse.c

Re: [PATCH] livepatch: Update maintainers

boeuf > -M: Seth Jennings > +M: Jessica Yu > M: Jiri Kosina > -M: Vojtech Pavlik > +M: Miroslav Benes > +R: Petr Mladek > S: Maintained > F: kernel/livepatch/ > F: include/linux/livepatch.h Acked-by: Miroslav Benes

Re: [PATCH] livepatch: Add some basic LivePatch documentation

> > potential developers of the framework itself. > > Thanks for starting the efforts; this is really needed if we want the > infrastructure to be used also by someone else than its developers :) Indeed. Great job, Petr. > [ ... snip ... ] > > +7. Limitations > &g

Re: [PATCH] livepatch: Add some basic LivePatch documentation

> > potential developers of the framework itself. > > Thanks for starting the efforts; this is really needed if we want the > infrastructure to be used also by someone else than its developers :) Indeed. Great job, Petr. > [ ... snip ... ] > > +7. Limitations > &g

<    5   6   7   8   9   10   11   12   13   >