objtool reports the following warnings for __schedule(): objtool: kernel/sched/core.o: __schedule()+0x3c0: duplicate frame pointer save objtool: kernel/sched/core.o: __schedule()+0x3fd: sibling call from callable instruction with changed frame pointer objtool: kernel/sched/core.o: __schedule()+0x40a: call without frame pointer save/setup objtool: kernel/sched/core.o: __schedule()+0x7fd: frame pointer state mismatch objtool: kernel/sched/core.o: __schedule()+0x421: frame pointer state mismatch Basically it's confused by two unusual attributes of the switch_to() macro: 1. It saves prev's frame pointer to the old stack and restores next's frame pointer from the new stack. 2. For new tasks it jumps directly to ret_from_fork. Eventually it would probably be a good idea to clean up the ret_from_fork hack so that new tasks are created with a valid initial stack, as suggested by Andy: https://lkml.kernel.org/r/CALCETrWsqCw4L1qKO9j9L5F+4ED4viuLQTFc=n1pKBZfFPQUFg@xxxxxxxxxxxxxx Then __schedule() could return normally into the new code and objtool hopefully wouldn't have a problem anymore. In the meantime, add it to the objtool whitelist so we can have a baseline with no objtool warnings. The marker also serves as a reminder that this code could be improved a bit. Signed-off-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> --- kernel/sched/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 9503d59..7ddee8d 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -74,6 +74,7 @@ #include <linux/binfmts.h> #include <linux/context_tracking.h> #include <linux/compiler.h> +#include <linux/objtool.h> #include <asm/switch_to.h> #include <asm/tlb.h> @@ -3288,6 +3289,7 @@ static void __sched notrace __schedule(bool preempt) balance_callback(rq); } +STACK_FRAME_NON_STANDARD(__schedule); /* switch_to() */ static inline void sched_submit_work(struct task_struct *tsk) { -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
