Messages in this thread | | | Date | Tue, 22 Nov 2022 17:23:50 -0800 | From | Josh Poimboeuf <> | 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.
o_O
How the @#$% is that a valid way of doing it? Why not just do it the normal way?
> Perhaps the best way would be to stick a REACHABLE annotation in > arch_cpu_idle_dead() or something?
It what universe would we expect a function named "play_dead" to instead finish bringing the CPU up and return?
That's just awful... I don't see anything "valid" about it.
-- Josh
| |