On (03/31/17 10:28), Eric W. Biederman wrote:
> ... I'd also probably add pr_emerg() print-out to
> the same way kernel_restart()/kernel_halt()/kernel_power_off() do.
> for those cases when emergency_restart() is called with printk in
> kthreaded mode, not in emergency mode.
No. No. No.
emergency_restart should be the equivalent of a watchdog going off.
AKA it is long past the point where you want to be coordinating
with other parts of the kernel. Rebooting is the priority.
A print statement absolutely does not belong in emergency_restart.
The fact that nothing managed to get printed out without magic flushing
code is highly disturbing.
Eric, have you checked what is usually going on right before the
a quick grep.
pr_emerg("Kernel panic - not syncing: %s\n", buf);
printk(KERN_CRIT "Executing emergency reboot\n");
pr_info("SysRq : ");
and so on...
all those printk()-s, that are happening right before emergency_restart(),
in fact flush (!) all the pending logbuf messages to the serial console.
and seems it doesn't cause any troubles on you side. but having printk()
not one line _before_the emergency_restart(), but _in_ emergency_restart()
is all of a sudden very disturbing. how come?
Looking from the outside this patchset appears to be broken by
If you don't want kernel functions suffering from the overhead of
printing to a slow output device, don't do that then.
sorry, this is not productive. "don't use printk()" is not a solution.
The point of printk is to give debugging output. You have
incapacitated printk from serving it's primary purpose.
the point of the patch set is that printk has a fundamental issue -- it
can easily soft/hard lockup the system; it can stall RCU; it can cause
OOM; and so on and on and on.