Re: Handling panics inside vt(4) callbacks

On 13/04/2023 17:18, Mark Johnston wrote:
> On Wed, Apr 12, 2023 at 10:45:27PM +0200, Jean-Sébastien Pédron wrote:
>> I could not find something in panic(9) code that would reboot the
>> computer in case of a nested panic.
> 
> In the case of a nested panic, vpanic() will not set RB_DUMP when it
> calls kern_reboot(), so it won't write a kernel dump.  And, if
> debug.debugger_on_recursive_panic is not set, the kernel will not try to
> re-enter the debugger.  So the kernel will simply reboot.

That was exactly the problem and I missed it even though I read that 
function many times... Thank you very much!

If I always set RB_DUMP, it does what I want in the context of that 
forced nested panic. I will continue to test with the DRM driver and the 
actual issues I'm currently chasing. Once done, I will prepare a patch.

> Perhaps we should set RB_DUMP in the case of a recursive panic so long
> as dumping == 0, i.e., we did not panic again while trying to dump core.
> In fact, kern_reboot() already checks this.

In fact, "kern_reboot()" already verify if "dumping" is non-zero. I 
think "vpanic()" could set the flag regardless of that variable.

Thank you!

-- 
Jean-Sébastien Pédron
The FreeBSD Project