Otherwise the system will burn even brighter and worse, leave the user wondering what's going on exactly.
Since we already have a panic handler which will (try) to restore the entire fbdev console mode, we can just bail out. Inspired by a patch from Konstantin Khlebnikov. The callchain leading to this, cut&pasted from Konstantin's original patch:
callstack: panic() bust_spinlocks(1) unblank_screen() vc->vc_sw->con_blank() fbcon_blank() fb_blank() info->fbops->fb_blank() drm_fb_helper_blank() drm_fb_helper_dpms() drm_modeset_lock_all() mutex_lock(&dev->mode_config.mutex)
Note that the entire locking in the fb helper around panic/sysrq and kdbg is ... non-existant. So we have a decent change of blowing up everything. But since reworking this ties in with funny concepts like the fbdev notifier chain or the impressive things which happen around console_lock while oopsing, I'll leave that as an exercise for braver souls than me.
Cc: Konstantin Khlebnikov khlebnikov@openvz.org Cc: Andrew Morton akpm@linux-foundation.org References: https://patchwork.kernel.org/patch/1878181/ Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch --- drivers/gpu/drm/drm_fb_helper.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index b774101..a3b4ecf 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -371,6 +371,14 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) int i, j;
/* + * fbdev->blank can be called from irq context in case of a panic. + * Since we already have our own special panic handler which will + * restore the fbdev console mode completely, just bail out early. + */ + if (oops_in_progress) + return -EBUSY; + + /* * For each CRTC in this fb, turn the connectors on/off. */ drm_modeset_lock_all(dev);