* Pavel Machek wrote:
> Hi!
>
> > > in terms of hit-patching kernels you are correct.
> > >
> > > but that's a far cry from what it sounded like you were demanding
> > > (that it must handle any kernel patch)
> >
> > No, I was not demanding that at all, my suggestion was:
> >
> >> My
* Pavel Machek pa...@ucw.cz wrote:
Hi!
in terms of hit-patching kernels you are correct.
but that's a far cry from what it sounded like you were demanding
(that it must handle any kernel patch)
No, I was not demanding that at all, my suggestion was:
My claim is
Hi!
> > in terms of hit-patching kernels you are correct.
> >
> > but that's a far cry from what it sounded like you were demanding
> > (that it must handle any kernel patch)
>
> No, I was not demanding that at all, my suggestion was:
>
>> My claim is that if a patch is correct/safe in
Hi!
in terms of hit-patching kernels you are correct.
but that's a far cry from what it sounded like you were demanding
(that it must handle any kernel patch)
No, I was not demanding that at all, my suggestion was:
My claim is that if a patch is correct/safe in the old
On Tue, May 20, 2014 at 11:37:16AM +0200, Jiri Kosina wrote:
> On Fri, 16 May 2014, Josh Poimboeuf wrote:
>
> > > Consider this scenario:
> > >
> > > void foo()
> > > {
> > > for (i=0; i<1; i++) {
> > > bar(i);
> > > something_else(i);
> > >
On Fri, 16 May 2014, Josh Poimboeuf wrote:
> > Consider this scenario:
> >
> > void foo()
> > {
> > for (i=0; i<1; i++) {
> > bar(i);
> > something_else(i);
> > }
> > }
> >
> > Let's say you want to live-patch
On Fri, 16 May 2014, Josh Poimboeuf wrote:
Consider this scenario:
void foo()
{
for (i=0; i1; i++) {
bar(i);
something_else(i);
}
}
Let's say you want to live-patch bar(). With
On Tue, May 20, 2014 at 11:37:16AM +0200, Jiri Kosina wrote:
On Fri, 16 May 2014, Josh Poimboeuf wrote:
Consider this scenario:
void foo()
{
for (i=0; i1; i++) {
bar(i);
something_else(i);
}
}
On Sat, May 17, 2014 at 03:09:57AM +0900, Masami Hiramatsu wrote:
> (2014/05/17 1:27), Jiri Kosina wrote:
> > On Tue, 6 May 2014, Steven Rostedt wrote:
> >
> >>> However, I also think if users can accept such freezing wait-time,
> >>> it means they can also accept kexec based "checkpoint-restart"
On Fri, 16 May 2014, Steven Rostedt wrote:
> Why I still favor the stop_machine approach, is because the method of
> patching is a bit simpler that way. A "lazy" approach will be more
> complex and more likely to be buggy. The thing I'm arguing here is not
> the end result being a problem, but
On Fri, 16 May 2014, Steven Rostedt wrote:
Why I still favor the stop_machine approach, is because the method of
patching is a bit simpler that way. A lazy approach will be more
complex and more likely to be buggy. The thing I'm arguing here is not
the end result being a problem, but the
On Sat, May 17, 2014 at 03:09:57AM +0900, Masami Hiramatsu wrote:
(2014/05/17 1:27), Jiri Kosina wrote:
On Tue, 6 May 2014, Steven Rostedt wrote:
However, I also think if users can accept such freezing wait-time,
it means they can also accept kexec based checkpoint-restart patching.
On Sat, 17 May 2014 00:32:10 +0200 (CEST)
Jiri Kosina wrote:
> That's true, and we come back to what has been said at the very beginning
> for both aproaches -- you can't really get away without manual human
> inspection of the patches that are being applied.
>
> The case you have outlined
On Fri, 16 May 2014, Steven Rostedt wrote:
> > With lazy-switching implemented in kgraft, this can never happen.
> >
> > So I'd like to ask for a little bit more explanation why you think the
> > stop_machine()-based patching provides more sanity/consistency assurance
> > than the lazy
On Fri, 16 May 2014 18:27:27 +0200 (CEST)
Jiri Kosina wrote:
> > ftrace did the stop_machine (and still does for some archs), and slowly
> > moved to a more efficient method. kpatch/kgraft should follow suit.
>
> I don't really agree here.
>
> I actually believe that "lazy" switching kgraft
(2014/05/17 1:27), Jiri Kosina wrote:
> On Tue, 6 May 2014, Steven Rostedt wrote:
>
>>> However, I also think if users can accept such freezing wait-time,
>>> it means they can also accept kexec based "checkpoint-restart" patching.
>>> So, I think the final goal of the kpatch will be live
On Fri, May 16, 2014 at 06:27:27PM +0200, Jiri Kosina wrote:
> On Tue, 6 May 2014, Steven Rostedt wrote:
>
> > > However, I also think if users can accept such freezing wait-time,
> > > it means they can also accept kexec based "checkpoint-restart" patching.
> > > So, I think the final goal of
On Tue, 6 May 2014, Steven Rostedt wrote:
> > However, I also think if users can accept such freezing wait-time,
> > it means they can also accept kexec based "checkpoint-restart" patching.
> > So, I think the final goal of the kpatch will be live patching without
> > stopping the machine. I'm
On Tue, 6 May 2014, Steven Rostedt wrote:
However, I also think if users can accept such freezing wait-time,
it means they can also accept kexec based checkpoint-restart patching.
So, I think the final goal of the kpatch will be live patching without
stopping the machine. I'm discussing
On Fri, May 16, 2014 at 06:27:27PM +0200, Jiri Kosina wrote:
On Tue, 6 May 2014, Steven Rostedt wrote:
However, I also think if users can accept such freezing wait-time,
it means they can also accept kexec based checkpoint-restart patching.
So, I think the final goal of the kpatch will
(2014/05/17 1:27), Jiri Kosina wrote:
On Tue, 6 May 2014, Steven Rostedt wrote:
However, I also think if users can accept such freezing wait-time,
it means they can also accept kexec based checkpoint-restart patching.
So, I think the final goal of the kpatch will be live patching without
On Fri, 16 May 2014 18:27:27 +0200 (CEST)
Jiri Kosina jkos...@suse.cz wrote:
ftrace did the stop_machine (and still does for some archs), and slowly
moved to a more efficient method. kpatch/kgraft should follow suit.
I don't really agree here.
I actually believe that lazy switching
On Fri, 16 May 2014, Steven Rostedt wrote:
With lazy-switching implemented in kgraft, this can never happen.
So I'd like to ask for a little bit more explanation why you think the
stop_machine()-based patching provides more sanity/consistency assurance
than the lazy switching we're
On Sat, 17 May 2014 00:32:10 +0200 (CEST)
Jiri Kosina jkos...@suse.cz wrote:
That's true, and we come back to what has been said at the very beginning
for both aproaches -- you can't really get away without manual human
inspection of the patches that are being applied.
The case you have
(2014/05/08 21:48), Josh Poimboeuf wrote:
>> No, I was not demanding that at all, my suggestion was:
>>
>>> My claim is that if a patch is correct/safe in the old fashioned
>>> way, then a fundamental principle is that a live patching
>>> subsystem must either safely apply, or safely
(2014/05/08 21:48), Josh Poimboeuf wrote:
No, I was not demanding that at all, my suggestion was:
My claim is that if a patch is correct/safe in the old fashioned
way, then a fundamental principle is that a live patching
subsystem must either safely apply, or safely reject the
(2014/05/09 10:46), David Lang wrote:
> On Wed, 7 May 2014, Ingo Molnar wrote:
>
>> * Josh Poimboeuf wrote:
>>
>>> On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
* Jiri Kosina wrote:
> On Mon, 5 May 2014, David Lang wrote:
>
>> how would you know that
On Thu, 2014-05-08 at 18:46 -0700, David Lang wrote:
> On Wed, 7 May 2014, Ingo Molnar wrote:
> It's possible to have two versions of code that each work independently, but
> that you can't switch between easily on the fly.
>
> If the new code assumes a lock is held that the old code didn't
On Wed, 7 May 2014, Ingo Molnar wrote:
* Josh Poimboeuf wrote:
On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
* Jiri Kosina wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched? just because
On Thu, May 08, 2014 at 09:08:15AM +0200, Ingo Molnar wrote:
>
> * David Lang wrote:
>
> > On Thu, 8 May 2014, Ingo Molnar wrote:
> >
> > >>>
> > >>>No!
> > >>>
> > >>>A patch to the kernel source is 'safe' if it results in a correctly
> > >>>patched kernel source. Full stop!
> > >>>
> >
(2014/05/08 16:08), Ingo Molnar wrote:
>
> * David Lang wrote:
>
>> On Thu, 8 May 2014, Ingo Molnar wrote:
>>
>
> No!
>
> A patch to the kernel source is 'safe' if it results in a correctly
> patched kernel source. Full stop!
>
> Live patching does not enter into
* David Lang wrote:
> On Thu, 8 May 2014, Ingo Molnar wrote:
>
> >>>
> >>>No!
> >>>
> >>>A patch to the kernel source is 'safe' if it results in a correctly
> >>>patched kernel source. Full stop!
> >>>
> >>>Live patching does not enter into this question, ever. The correctness
> >>>of a patch
On Thu, 8 May 2014, Ingo Molnar wrote:
No!
A patch to the kernel source is 'safe' if it results in a correctly
patched kernel source. Full stop!
Live patching does not enter into this question, ever. The correctness
of a patch to the source does not depend on 'live patching'
considerations
* David Lang wrote:
> On Wed, 7 May 2014, Ingo Molnar wrote:
>
> >* Josh Poimboeuf wrote:
> >
> >>On Wed, May 07, 2014 at 02:24:44PM +0200, Ingo Molnar wrote:
> >>>
> >>>* Josh Poimboeuf wrote:
> >>>
> >Ah this reminds me when we chased kprobes dangerous spots and we
> >tried to
* David Lang da...@lang.hm wrote:
On Wed, 7 May 2014, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
On Wed, May 07, 2014 at 02:24:44PM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
Ah this reminds me when we chased kprobes dangerous spots and
On Thu, 8 May 2014, Ingo Molnar wrote:
No!
A patch to the kernel source is 'safe' if it results in a correctly
patched kernel source. Full stop!
Live patching does not enter into this question, ever. The correctness
of a patch to the source does not depend on 'live patching'
considerations
* David Lang da...@lang.hm wrote:
On Thu, 8 May 2014, Ingo Molnar wrote:
No!
A patch to the kernel source is 'safe' if it results in a correctly
patched kernel source. Full stop!
Live patching does not enter into this question, ever. The correctness
of a patch to the source does
(2014/05/08 16:08), Ingo Molnar wrote:
* David Lang da...@lang.hm wrote:
On Thu, 8 May 2014, Ingo Molnar wrote:
No!
A patch to the kernel source is 'safe' if it results in a correctly
patched kernel source. Full stop!
Live patching does not enter into this question, ever. The
On Thu, May 08, 2014 at 09:08:15AM +0200, Ingo Molnar wrote:
* David Lang da...@lang.hm wrote:
On Thu, 8 May 2014, Ingo Molnar wrote:
No!
A patch to the kernel source is 'safe' if it results in a correctly
patched kernel source. Full stop!
Live patching does not enter
On Wed, 7 May 2014, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
* Jiri Kosina jkos...@suse.cz wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
On Thu, 2014-05-08 at 18:46 -0700, David Lang wrote:
On Wed, 7 May 2014, Ingo Molnar wrote:
It's possible to have two versions of code that each work independently, but
that you can't switch between easily on the fly.
If the new code assumes a lock is held that the old code didn't take,
(2014/05/09 10:46), David Lang wrote:
On Wed, 7 May 2014, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
* Jiri Kosina jkos...@suse.cz wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all
On Wed, 7 May 2014, Ingo Molnar wrote:
* Josh Poimboeuf wrote:
On Wed, May 07, 2014 at 02:24:44PM +0200, Ingo Molnar wrote:
* Josh Poimboeuf wrote:
Ah this reminds me when we chased kprobes dangerous spots and we
tried to declare __kprobes the functions which were too dangerous
to hot
On Wed, May 07, 2014 at 05:57:54PM +0200, Ingo Molnar wrote:
> Live patching does not enter into this question, ever. The correctness
> of a patch to the source does not depend on 'live patching'
> considerations in any way, shape or form.
>
> Any mechanism that tries to blur these lines is
* Josh Poimboeuf wrote:
> On Wed, May 07, 2014 at 02:24:44PM +0200, Ingo Molnar wrote:
> >
> > * Josh Poimboeuf wrote:
> >
> > > > Ah this reminds me when we chased kprobes dangerous spots and we
> > > > tried to declare __kprobes the functions which were too dangerous
> > > > to hot
On Wed, May 07, 2014 at 02:24:44PM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > > Ah this reminds me when we chased kprobes dangerous spots and we
> > > tried to declare __kprobes the functions which were too dangerous
> > > to hot patch.
> > >
> > > We eventually gave up
* Josh Poimboeuf wrote:
> > Ah this reminds me when we chased kprobes dangerous spots and we
> > tried to declare __kprobes the functions which were too dangerous
> > to hot patch.
> >
> > We eventually gave up because it was impossible to fix everything.
> > And that was only for kprobes!
* Josh Poimboeuf wrote:
> On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
> >
> > * Jiri Kosina wrote:
> >
> > > On Mon, 5 May 2014, David Lang wrote:
> > >
> > > > how would you know that all instances of the datastructure in memory
> > > > have= been touched? just because
* Josh Poimboeuf jpoim...@redhat.com wrote:
On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
* Jiri Kosina jkos...@suse.cz wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched?
* Josh Poimboeuf jpoim...@redhat.com wrote:
Ah this reminds me when we chased kprobes dangerous spots and we
tried to declare __kprobes the functions which were too dangerous
to hot patch.
We eventually gave up because it was impossible to fix everything.
And that was only for
On Wed, May 07, 2014 at 02:24:44PM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
Ah this reminds me when we chased kprobes dangerous spots and we
tried to declare __kprobes the functions which were too dangerous
to hot patch.
We eventually gave up
* Josh Poimboeuf jpoim...@redhat.com wrote:
On Wed, May 07, 2014 at 02:24:44PM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
Ah this reminds me when we chased kprobes dangerous spots and we
tried to declare __kprobes the functions which were too
On Wed, May 07, 2014 at 05:57:54PM +0200, Ingo Molnar wrote:
Live patching does not enter into this question, ever. The correctness
of a patch to the source does not depend on 'live patching'
considerations in any way, shape or form.
Any mechanism that tries to blur these lines is broken
On Wed, 7 May 2014, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
On Wed, May 07, 2014 at 02:24:44PM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
Ah this reminds me when we chased kprobes dangerous spots and we
tried to declare __kprobes the
(2014/05/06 21:33), Steven Rostedt wrote:
> On Tue, 6 May 2014 07:12:11 -0500
> Josh Poimboeuf wrote:
>
>> Live patching is a very sensitive and risky operation, and from a kernel
>> standpoint we should make it as safe as we reasonably can. But we can't
>> do much about careless users.
(2014/05/06 21:26), Steven Rostedt wrote:
> On Tue, 06 May 2014 20:45:50 +0900
> Masami Hiramatsu wrote:
>
>
>> However, I also think if users can accept such freezing wait-time,
>> it means they can also accept kexec based "checkpoint-restart" patching.
>> So, I think the final goal of the
On Tue, May 06, 2014 at 04:05:21PM +0200, Frederic Weisbecker wrote:
> On Tue, May 06, 2014 at 07:12:11AM -0500, Josh Poimboeuf wrote:
> > On Mon, May 05, 2014 at 11:49:23PM +0200, Frederic Weisbecker wrote:
> > > On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
> > > > If a kernel
On Tue, May 06, 2014 at 07:12:11AM -0500, Josh Poimboeuf wrote:
> On Mon, May 05, 2014 at 11:49:23PM +0200, Frederic Weisbecker wrote:
> > On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
> > > If a kernel refuses to patch with certain threads running, that will
> > > drive those
On Tue, 6 May 2014 07:12:11 -0500
Josh Poimboeuf wrote:
> Live patching is a very sensitive and risky operation, and from a kernel
> standpoint we should make it as safe as we reasonably can. But we can't
> do much about careless users. Ultimately the risk is in the hands of
> the user and
On Tue, 06 May 2014 20:45:50 +0900
Masami Hiramatsu wrote:
> However, I also think if users can accept such freezing wait-time,
> it means they can also accept kexec based "checkpoint-restart" patching.
> So, I think the final goal of the kpatch will be live patching without
> stopping the
On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
>
> * Jiri Kosina wrote:
>
> > On Mon, 5 May 2014, David Lang wrote:
> >
> > > how would you know that all instances of the datastructure in memory
> > > have= been touched? just because all tasks have run and are outside the
> > >
On Mon, May 05, 2014 at 06:59:29PM -0700, David Lang wrote:
> On Tue, 6 May 2014, Jiri Kosina wrote:
>
> >On Mon, 5 May 2014, David Lang wrote:
> >
> >>how would you know that all instances of the datastructure in memory
> >>have= been touched? just because all tasks have run and are outside the
On Mon, May 05, 2014 at 11:49:23PM +0200, Frederic Weisbecker wrote:
> On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
> > If a kernel refuses to patch with certain threads running, that will
> > drive those kernel threads being fixed and such. It's a deterministic,
> > recoverable,
(2014/05/06 3:43), Ingo Molnar wrote:
>
> * Frederic Weisbecker wrote:
>
>> On Mon, May 05, 2014 at 08:26:38AM -0500, Josh Poimboeuf wrote:
>>> On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
* Josh Poimboeuf wrote:
> [...]
>
> kpatch checks the
On Tue, 6 May 2014, Ingo Molnar wrote:
> So what I'm curious about, what is the actual 'in the field' distro
> experience, about the type of live-patches that get pushed with
> urgency?
This is of course a very good question. We've done some very light
preparatory analysis and went through
* Jiri Kosina wrote:
> On Mon, 5 May 2014, David Lang wrote:
>
> > how would you know that all instances of the datastructure in memory
> > have= been touched? just because all tasks have run and are outside the
> > function in question doesn't tell you data structures have been
> >
(2014/05/06 21:26), Steven Rostedt wrote:
On Tue, 06 May 2014 20:45:50 +0900
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
However, I also think if users can accept such freezing wait-time,
it means they can also accept kexec based checkpoint-restart patching.
So, I think the
(2014/05/06 21:33), Steven Rostedt wrote:
On Tue, 6 May 2014 07:12:11 -0500
Josh Poimboeuf jpoim...@redhat.com wrote:
Live patching is a very sensitive and risky operation, and from a kernel
standpoint we should make it as safe as we reasonably can. But we can't
do much about careless
* Jiri Kosina jkos...@suse.cz wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched? just because all tasks have run and are outside the
function in question doesn't tell you data structures have been
On Tue, 6 May 2014, Ingo Molnar wrote:
So what I'm curious about, what is the actual 'in the field' distro
experience, about the type of live-patches that get pushed with
urgency?
This is of course a very good question. We've done some very light
preparatory analysis and went through
(2014/05/06 3:43), Ingo Molnar wrote:
* Frederic Weisbecker fweis...@gmail.com wrote:
On Mon, May 05, 2014 at 08:26:38AM -0500, Josh Poimboeuf wrote:
On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
[...]
kpatch checks the
On Mon, May 05, 2014 at 11:49:23PM +0200, Frederic Weisbecker wrote:
On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
If a kernel refuses to patch with certain threads running, that will
drive those kernel threads being fixed and such. It's a deterministic,
recoverable,
On Mon, May 05, 2014 at 06:59:29PM -0700, David Lang wrote:
On Tue, 6 May 2014, Jiri Kosina wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched? just because all tasks have run and are outside the
function in
On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
* Jiri Kosina jkos...@suse.cz wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched? just because all tasks have run and are outside the
On Tue, 06 May 2014 20:45:50 +0900
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
However, I also think if users can accept such freezing wait-time,
it means they can also accept kexec based checkpoint-restart patching.
So, I think the final goal of the kpatch will be live patching
On Tue, 6 May 2014 07:12:11 -0500
Josh Poimboeuf jpoim...@redhat.com wrote:
Live patching is a very sensitive and risky operation, and from a kernel
standpoint we should make it as safe as we reasonably can. But we can't
do much about careless users. Ultimately the risk is in the hands of
On Tue, May 06, 2014 at 07:12:11AM -0500, Josh Poimboeuf wrote:
On Mon, May 05, 2014 at 11:49:23PM +0200, Frederic Weisbecker wrote:
On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
If a kernel refuses to patch with certain threads running, that will
drive those kernel
On Tue, May 06, 2014 at 04:05:21PM +0200, Frederic Weisbecker wrote:
On Tue, May 06, 2014 at 07:12:11AM -0500, Josh Poimboeuf wrote:
On Mon, May 05, 2014 at 11:49:23PM +0200, Frederic Weisbecker wrote:
On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
If a kernel refuses to
On Tue, 6 May 2014, Jiri Kosina wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched? just because all tasks have run and are outside the
function in question doesn't tell you data structures have been
converted.
On Mon, 5 May 2014, David Lang wrote:
> how would you know that all instances of the datastructure in memory
> have= been touched? just because all tasks have run and are outside the
> function in question doesn't tell you data structures have been
> converted. You have n= o way of knowing
On Fri, 2 May 2014, Jiri Kosina wrote:
On Thu, 1 May 2014, Josh Poimboeuf wrote:
kpatch vs kGraft
I think the biggest difference between kpatch and kGraft is how they
ensure that the patch is applied atomically and safely.
kpatch checks the backtraces of all tasks in
On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
>
> * Frederic Weisbecker wrote:
>
> > On Mon, May 05, 2014 at 08:26:38AM -0500, Josh Poimboeuf wrote:
> > > On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
> > > >
> > > > * Josh Poimboeuf wrote:
> > > >
> > > > >
* Frederic Weisbecker wrote:
> On Mon, May 05, 2014 at 08:26:38AM -0500, Josh Poimboeuf wrote:
> > On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
> > >
> > > * Josh Poimboeuf wrote:
> > >
> > > > [...]
> > > >
> > > > kpatch checks the backtraces of all tasks in stop_machine()
On Mon, May 05, 2014 at 08:26:38AM -0500, Josh Poimboeuf wrote:
> On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
> >
> > * Josh Poimboeuf wrote:
> >
> > > [...]
> > >
> > > kpatch checks the backtraces of all tasks in stop_machine() to
> > > ensure that no instances of the old
On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > [...]
> >
> > kpatch checks the backtraces of all tasks in stop_machine() to
> > ensure that no instances of the old function are running when the
> > new function is applied. I think the biggest
* Josh Poimboeuf wrote:
> [...]
>
> kpatch checks the backtraces of all tasks in stop_machine() to
> ensure that no instances of the old function are running when the
> new function is applied. I think the biggest downside of this
> approach is that stop_machine() has to idle all other
* Josh Poimboeuf jpoim...@redhat.com wrote:
[...]
kpatch checks the backtraces of all tasks in stop_machine() to
ensure that no instances of the old function are running when the
new function is applied. I think the biggest downside of this
approach is that stop_machine() has to idle
On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
[...]
kpatch checks the backtraces of all tasks in stop_machine() to
ensure that no instances of the old function are running when the
new function is applied. I think the
On Mon, May 05, 2014 at 08:26:38AM -0500, Josh Poimboeuf wrote:
On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
[...]
kpatch checks the backtraces of all tasks in stop_machine() to
ensure that no instances of the old
* Frederic Weisbecker fweis...@gmail.com wrote:
On Mon, May 05, 2014 at 08:26:38AM -0500, Josh Poimboeuf wrote:
On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
[...]
kpatch checks the backtraces of all tasks in
On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
* Frederic Weisbecker fweis...@gmail.com wrote:
On Mon, May 05, 2014 at 08:26:38AM -0500, Josh Poimboeuf wrote:
On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
On Fri, 2 May 2014, Jiri Kosina wrote:
On Thu, 1 May 2014, Josh Poimboeuf wrote:
kpatch vs kGraft
I think the biggest difference between kpatch and kGraft is how they
ensure that the patch is applied atomically and safely.
kpatch checks the backtraces of all tasks in
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched? just because all tasks have run and are outside the
function in question doesn't tell you data structures have been
converted. You have n= o way of knowing when
On Tue, 6 May 2014, Jiri Kosina wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched? just because all tasks have run and are outside the
function in question doesn't tell you data structures have been
converted.
On Fri, May 02, 2014 at 03:10:58PM +0200, Jiri Kosina wrote:
> On Thu, 1 May 2014, Josh Poimboeuf wrote:
>
> > kpatch vs kGraft
> >
> >
> > I think the biggest difference between kpatch and kGraft is how they
> > ensure that the patch is applied atomically and safely.
> >
> >
On Fri, May 02, 2014 at 10:37:53AM +0200, Jiri Kosina wrote:
> On Thu, 1 May 2014, Josh Poimboeuf wrote:
>
> > Since Jiri posted the kGraft patches [1], I wanted to share an
> > alternative live patching solution called kpatch, which is something
> > we've been working on at Red Hat for quite a
On Thu, 1 May 2014, Josh Poimboeuf wrote:
> kpatch vs kGraft
>
>
> I think the biggest difference between kpatch and kGraft is how they
> ensure that the patch is applied atomically and safely.
>
> kpatch checks the backtraces of all tasks in stop_machine() to ensure
> that no
On Thu, 1 May 2014, Josh Poimboeuf wrote:
> Since Jiri posted the kGraft patches [1], I wanted to share an
> alternative live patching solution called kpatch, which is something
> we've been working on at Red Hat for quite a while.
Hi Josh, Seth,
thanks a lot for following up to our RFC with
On Thu, 1 May 2014, Josh Poimboeuf wrote:
Since Jiri posted the kGraft patches [1], I wanted to share an
alternative live patching solution called kpatch, which is something
we've been working on at Red Hat for quite a while.
Hi Josh, Seth,
thanks a lot for following up to our RFC with your
On Thu, 1 May 2014, Josh Poimboeuf wrote:
kpatch vs kGraft
I think the biggest difference between kpatch and kGraft is how they
ensure that the patch is applied atomically and safely.
kpatch checks the backtraces of all tasks in stop_machine() to ensure
that no
1 - 100 of 114 matches
Mail list logo
