Messages in this thread | | | Date | Thu, 1 May 2014 16:39:29 -0500 | From | Josh Poimboeuf <> | Subject | Re: [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
| |