On Thu 2016-04-28 13:53:53, Josh Poimboeuf wrote:
> On Tue, Apr 05, 2016 at 08:44:30AM -0500, Josh Poimboeuf wrote:
> > On Fri, Apr 01, 2016 at 03:39:44PM +0200, Petr Mladek wrote:
> > > > There's also a func->immediate flag which allows users to specify that
> > > > certain functions in the patch
On Thu 2016-04-28 13:53:53, Josh Poimboeuf wrote:
> On Tue, Apr 05, 2016 at 08:44:30AM -0500, Josh Poimboeuf wrote:
> > On Fri, Apr 01, 2016 at 03:39:44PM +0200, Petr Mladek wrote:
> > > > There's also a func->immediate flag which allows users to specify that
> > > > certain functions in the patch
On Tue, Apr 05, 2016 at 08:44:30AM -0500, Josh Poimboeuf wrote:
> On Fri, Apr 01, 2016 at 03:39:44PM +0200, Petr Mladek wrote:
> > > There's also a func->immediate flag which allows users to specify that
> > > certain functions in the patch can be applied without per-task
> > > consistency. This
On Tue, Apr 05, 2016 at 08:44:30AM -0500, Josh Poimboeuf wrote:
> On Fri, Apr 01, 2016 at 03:39:44PM +0200, Petr Mladek wrote:
> > > There's also a func->immediate flag which allows users to specify that
> > > certain functions in the patch can be applied without per-task
> > > consistency. This
On Thu, 7 Apr 2016, Josh Poimboeuf wrote:
> > I admittedly forgot what the "ftrace handler switching idea" is, and am
> > not sure where exactly to look for it (could you please point it to me so
> > that I can refresh my memory)
>
> Here's where I originally described it [1]:
Thanks!
> | 2)
On Thu, 7 Apr 2016, Josh Poimboeuf wrote:
> > I admittedly forgot what the "ftrace handler switching idea" is, and am
> > not sure where exactly to look for it (could you please point it to me so
> > that I can refresh my memory)
>
> Here's where I originally described it [1]:
Thanks!
> | 2)
On Thu, Apr 07, 2016 at 05:47:00PM +0200, Jiri Kosina wrote:
> On Thu, 7 Apr 2016, Josh Poimboeuf wrote:
>
> > > > - try ftrace handler switching idea from v1 cover letter
> [ ... ]
> > > We probably should not check the stack in atomic context
> >
> > Can you elaborate why not?
>
> I
On Thu, Apr 07, 2016 at 05:47:00PM +0200, Jiri Kosina wrote:
> On Thu, 7 Apr 2016, Josh Poimboeuf wrote:
>
> > > > - try ftrace handler switching idea from v1 cover letter
> [ ... ]
> > > We probably should not check the stack in atomic context
> >
> > Can you elaborate why not?
>
> I
On Thu, 7 Apr 2016, Josh Poimboeuf wrote:
> > > - try ftrace handler switching idea from v1 cover letter
[ ... ]
> > We probably should not check the stack in atomic context
>
> Can you elaborate why not?
I admittedly forgot what the "ftrace handler switching idea" is, and am
not sure where
On Thu, 7 Apr 2016, Josh Poimboeuf wrote:
> > > - try ftrace handler switching idea from v1 cover letter
[ ... ]
> > We probably should not check the stack in atomic context
>
> Can you elaborate why not?
I admittedly forgot what the "ftrace handler switching idea" is, and am
not sure where
On Thu, Apr 07, 2016 at 02:10:30PM +0200, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> > TODO:
> > - try ftrace handler switching idea from v1 cover letter
>
> I have had a discussion about it with Mirek. This would help with
> kthreads. If they are sleeping in a
On Thu, Apr 07, 2016 at 02:10:30PM +0200, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> > TODO:
> > - try ftrace handler switching idea from v1 cover letter
>
> I have had a discussion about it with Mirek. This would help with
> kthreads. If they are sleeping in a
On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> TODO:
> - try ftrace handler switching idea from v1 cover letter
I have had a discussion about it with Mirek. This would help with
kthreads. If they are sleeping in a patched function, we wake
them up, this will help to migrate them before they
On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> TODO:
> - try ftrace handler switching idea from v1 cover letter
I have had a discussion about it with Mirek. This would help with
kthreads. If they are sleeping in a patched function, we wake
them up, this will help to migrate them before they
On Tue 2016-04-05 08:44:30, Josh Poimboeuf wrote:
> On Fri, Apr 01, 2016 at 03:39:44PM +0200, Petr Mladek wrote:
> > On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> > > - update documentation for sysfs, proc, livepatch
> >
> > Also we should publish somewhere the information about
On Tue 2016-04-05 08:44:30, Josh Poimboeuf wrote:
> On Fri, Apr 01, 2016 at 03:39:44PM +0200, Petr Mladek wrote:
> > On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> > > - update documentation for sysfs, proc, livepatch
> >
> > Also we should publish somewhere the information about
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 accelerate a migration to a new universe. We
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 accelerate a migration to a new universe. We
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 accelerate a migration to a new universe. We have it in kgraft for
> > > quite some time and it
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 accelerate a migration to a new universe. We have it in kgraft for
> > > quite some time and it
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
> >
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
> >
On Fri, Apr 01, 2016 at 03:39:44PM +0200, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> > These patches are still a work in progress, but Jiri asked that I share
> > them before I go on vacation next week. Based on origin/master because
> > it has
On Fri, Apr 01, 2016 at 03:39:44PM +0200, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> > These patches are still a work in progress, but Jiri asked that I share
> > them before I go on vacation next week. Based on origin/master because
> > it has
On Thu, Mar 31, 2016 at 02:54:26PM +0200, Miroslav Benes wrote:
>
> 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
On Thu, Mar 31, 2016 at 02:54:26PM +0200, Miroslav Benes wrote:
>
> 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
On Fri 2016-04-01 15:39:44, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> > These patches are still a work in progress, but Jiri asked that I share
> > them before I go on vacation next week. Based on origin/master because
> > it has CONFIG_STACK_VALIDATION.
>
> I have
On Fri 2016-04-01 15:39:44, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> > These patches are still a work in progress, but Jiri asked that I share
> > them before I go on vacation next week. Based on origin/master because
> > it has CONFIG_STACK_VALIDATION.
>
> I have
On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> These patches are still a work in progress, but Jiri asked that I share
> them before I go on vacation next week. Based on origin/master because
> it has CONFIG_STACK_VALIDATION.
I have to follow Mirek and say that it is a great work.
>
On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> These patches are still a work in progress, but Jiri asked that I share
> them before I go on vacation next week. Based on origin/master because
> it has CONFIG_STACK_VALIDATION.
I have to follow Mirek and say that it is a great work.
>
> - 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
> - 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
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
>
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
>
These patches are still a work in progress, but Jiri asked that I share
them before I go on vacation next week. Based on origin/master because
it has CONFIG_STACK_VALIDATION.
This has two consistency models: the immediate model (like in today's
code) and the new kpatch/kgraft hybrid model.
The
These patches are still a work in progress, but Jiri asked that I share
them before I go on vacation next week. Based on origin/master because
it has CONFIG_STACK_VALIDATION.
This has two consistency models: the immediate model (like in today's
code) and the new kpatch/kgraft hybrid model.
The
36 matches
Mail list logo
