lkml.org 
[lkml]   [2014]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/2] kpatch: dynamic kernel patching
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 is no problem, you see it in the backtrace.
> > But you don't see bar.
>
> Sorry, I missed your point the first time. Good question.
>
> stop_machine schedules a high priority thread on each CPU, which means
> every other task will be waiting in a schedule() call (assuming a
> non-preemptible kernel). In my local kernel, a quick grep of the
> disassembly doesn't show any jumps to schedule:
>
> $ egrep 'j.*<.*>' vmlinux.asm |grep -v '\+' |grep schedule
> ffffffff816b89b5: e9 e2 fe ff ff jmpq ffffffff816b889c <retint_with_reschedule>
> ffffffff816b8cec: 75 1e jne ffffffff816b8d0c <paranoid_schedule>
>
> But yes, that would be a problem if any tail call jumps to schedule()
> ever showed up. We may need to detect that case in our patch generation
> tooling and fail to create the patch module binary if the patch affects
> a function which does this.

Thinking more about this... Even if it jumps to schedule(), I think
there's no problem, since the function is basically done, and we already
know not to patch schedule().

--
Josh


\
 
 \ /
  Last update: 2014-05-02 00:21    [W:0.812 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site