Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

[Josh Poimboeuf]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/