Linux reboot() system call: why it calls do_exit(0) after kernel_halt()?

Question

This is related to: https://stackoverflow.com/a/13413099/1284631

Now, the question is:

Why the reboot() system call, when called with LINUX_REBOOT_CMD_HALT parameter (see here: http://lxr.linux.no/linux+v3.6.6/kernel/sys.c#L480) is calling do_exit(0) after having already called kernel_halt(), as calling kernel_halt() boils down to calling stop_this_cpu() (see here: http://lxr.linux.no/linux+v3.6.6/arch/x86/kernel/process.c#L519), as part of native_machine_halt() (see here: http://lxr.linux.no/linux+v3.6.6/arch/x86/kernel/reboot.c#L680).

Or, it seems to me that stop_this_cpu() is never returning (it ends with an infinite loop).

So, it is do_exit(0) called just in case that kernel_halt() doesn't do its job and it return? Why not panic() directly instead, then?

Answer 1

Some ideas:

• It may be that kernel_halt() refuses to actually halt for a legitimate reason, though I can't think of any.
• kernel_halt() may be designed to also be called by a hypervisor or something at a higher or equivalent level than the kernel (custom SMI code maybe?)
• Perhaps the kernel_halt() function returns early, "scheduling" the halt, and the actual halt takes place some time later on some hardware. I remember reading about performing an ATX power off in DOS in assembly - you would issue the outb instruction to intiate the power off, but you'd have to have some nops, an endless loop, or a hlt right afterward, as the actual power off could happen some cycles later.
• The calling process may wish to handle failure to reboot some other way than a kernel panic.