[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140501210154.GC3907@treble.redhat.com>
Date: Thu, 1 May 2014 16:01:54 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Seth Jennings <sjenning@...hat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Steven Rostedt <rostedt@...dmis.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...hat.com>, Jiri Slaby <jslaby@...e.cz>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching
On Thu, May 01, 2014 at 01:45:33PM -0700, Andi Kleen wrote:
> Josh Poimboeuf <jpoimboe@...hat.com> 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 ...
>
> When you backtrace you will see foo, but you are running in bar.
> Note that tail calls can be indirect, so they cannot be resolved
> statically.
>
> CONFIG_DEBUG_INFO usually disables tail calls, but not supporting
> it would seem like a large limitation, as the cost can be high.
>
> It wouldn't surprise me if there are some similar special cases that
> can even happen with them disabled.
>
> In theory you could read LBRs, but even that may miss some extreme
> cases.
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.
--
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists