* 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 cl
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
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 bar().
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 the
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 is
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 switchin
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 is
(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
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
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 dis
(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/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 all
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
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 a
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!
> > >>>
> > >>>Liv
(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 this
* 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 t
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 in
* 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 decla
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 pa
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 brok
* 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 patch.
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 becau
* 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 all
(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. Ultimat
(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 kpat
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 refu
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 kerne
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 thei
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 machi
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 backtrace
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 pat
* 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
> > converte
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. Y
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 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 stop_ma
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 fu
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 d
* 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 CPUs
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.
> >
> > kp
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 wh
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 i
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 you
(2014/05/02 6:06), Andi Kleen wrote:
>> When bar returns, would it skip foo and go straight back to foo's
>> caller? If so, then it should be safe to patch foo after it jumps to
>> bar.
>
> foo is no problem, you see it in the backtrace.
> But you don't see bar.
No, there is no "foo" in backtrac
On Thu, May 01, 2014 at 04:27:46PM -0500, Josh Poimboeuf wrote:
> On Thu, May 01, 2014 at 11:06:01PM +0200, Andi Kleen wrote:
> > > When bar returns, would it skip foo and go straight back to foo's
> > > caller? If so, then it should be safe to patch foo after it jumps to
> > > bar.
> >
> > foo i
On Thu, May 01, 2014 at 11:06:01PM +0200, Andi Kleen wrote:
> > When bar returns, would it skip foo and go straight back to foo's
> > caller? If so, then it should be safe to patch foo after it jumps to
> > bar.
>
> foo is no problem, you see it in the backtrace.
> But you don't see bar.
Sorry,
> When bar returns, would it skip foo and go straight back to foo's
> caller? If so, then it should be safe to patch foo after it jumps to
> bar.
foo is no problem, you see it in the backtrace.
But you don't see bar.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe
On Thu, May 01, 2014 at 01:45:33PM -0700, Andi Kleen wrote:
> Josh Poimboeuf writes:
> >
> > 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.
>
> How does that work for tail calls?
>
Josh Poimboeuf writes:
>
> 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.
How does that work for tail calls?
call foo
foo:
...
jmp bar
bar:
... code executing
57 matches
Mail list logo