Messages in this thread | | | Date | Tue, 22 Nov 2022 16:22:58 -0800 | From | "Paul E. McKenney" <> | Subject | Re: objtool warning for next-20221118 |
| |
On Tue, Nov 22, 2022 at 09:35:17AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2022 at 09:16:05PM -0800, Josh Poimboeuf wrote: > > > It's complaining about an unreachable instruction after a call to > > arch_cpu_idle_dead(). In this case objtool detects the fact > > arch_cpu_idle_dead() doesn't return due to its call to the > > non-CONFIG_SMP version of play_dead(). But GCC has no way of detecting > > that because the caller is in another translation unit. > > > > As far as I can tell, that function should never return. Though it > > seems to have some dubious semantics (see xen_pv_play_dead() for > > example, which *does* seem to return?). I'm thinking it would be an > > improvement to enforce that noreturn behavior across all arches and > > platforms, sprinkling __noreturn and BUG() on arch_cpu_idle_dead() and > > maybe some of it callees, where needed. > > > > Peter, what do you think? I could attempt a patch. > > I'm thinking the Xen case makes all this really rather difficult :/ > > While normally a CPU is brought up through a trampoline, Xen seems to > have implemented it by simply returning from play_dead(), and afaict > that is actually a valid way to go about doing it. > > Perhaps the best way would be to stick a REACHABLE annotation in > arch_cpu_idle_dead() or something?
When I apply this on -next, I still get the objtool complaint. Is there something else I should also be doing?
Thanx, Paul
> --- > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > index c21b7347a26d..0354be027eb0 100644 > --- a/arch/x86/kernel/process.c > +++ b/arch/x86/kernel/process.c > @@ -712,6 +712,7 @@ void arch_cpu_idle_enter(void) > void arch_cpu_idle_dead(void) > { > play_dead(); > + asm(ASM_REACHABLE); > } > > /*
| |