5

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?

Community
  • 1
  • 1
user1284631
  • 4,446
  • 36
  • 61
  • panic make kernel stall, exit, probably reboot – zb' Dec 11 '12 at 12:41
  • @eicto: yes, I agree with that, I said the same thing in the ending phrase of my post. The true question is: why the call to do_exit(0) *before* the panic()? If you want to make the kernel stall, exit or reboot, why do not call panic() directly? – user1284631 Dec 11 '12 at 15:38

1 Answers1

2

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.