| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 02 May 2014 10:30:57 +0900 From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> To: Andi Kleen <andi@...stfloor.org> Cc: Josh Poimboeuf <jpoimboe@...hat.com>, Seth Jennings <sjenning@...hat.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: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching (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 backtrace. As Josh said, stop_machine() schedules highest priority tasks on each running thread, as below. buz: ... call foo -> push buz on the stack foo: ... jmp bar bar: ... call schedule -> push bar on the stack Thus, we'll not see foo on the stack. However, since the tail call doesn't return to foo, we can treat it already finished. So, there is no consistency problem on it. :) Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@...achi.com -- 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