]> git.baikalelectronics.ru Git - kernel.git/commit
drm/fb-helper: don't sleep for screen unblank when an oopps is in progress
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Thu, 24 Jan 2013 15:42:07 +0000 (16:42 +0100)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Wed, 13 Feb 2013 23:08:33 +0000 (00:08 +0100)
commit6b4762867120df42dfd7180a042ff2c5dfb05a2c
tree8202c1fb814b335e319bd2e5a048db0d80be6f66
parent4cf7c7127abfcb09a3ee49f47c7a36a3661d737f
drm/fb-helper: don't sleep for screen unblank when an oopps is in progress

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.

v2: Drop the -EBUSY return value I've copied, we don't need it since
the we'll take care of things ourselves anyway.

Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
References: https://patchwork.kernel.org/patch/1878181/
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/drm_fb_helper.c