[PATCH] drm: fb helper should avoid sleeping in panic context
From: Rui WangThere are still some places in the fb helper that need to avoid sleeping in panic context. Here's an example: [ 65.615496] bad: scheduling from the idle thread! [ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G ME 3.18.0-rc4-7-default+ #20 [ 65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRHSXSD1.86B.0056.R01.1409242327 09/24/2014 [ 65.641923] 88087f693d80 88087f689878 81566db9 [ 65.650226] 88087f693d80 88087f689898 810871ff 88046eb3e0d0 [ 65.658527] 88087f693d80 88087f6898c8 8107c1fa 00017f6898b8 [ 65.666830] Call Trace: [ 65.669557] <#MC> [] dump_stack+0x46/0x58 [ 65.675994] [] dequeue_task_idle+0x2f/0x40 [ 65.682412] [] dequeue_task+0x5a/0x80 [ 65.688345] [] deactivate_task+0x23/0x30 [ 65.694569] [] __schedule+0x580/0x7f0 [ 65.700502] [] schedule_preempt_disabled+0x29/0x70 [ 65.707696] [] __ww_mutex_lock_slowpath+0xb8/0x162 [ 65.714891] [] __ww_mutex_lock+0x53/0x85 [ 65.721125] [] drm_modeset_lock+0x3d/0x110 [drm] [ 65.728132] [] __drm_modeset_lock_all+0x8a/0x120 [drm] [ 65.735721] [] drm_modeset_lock_all+0x10/0x30 [drm] [ 65.743015] [] drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper] [ 65.751857] [] fb_pan_display+0xd1/0x1a0 [ 65.758081] [] bit_update_start+0x20/0x50 [ 65.764400] [] fbcon_switch+0x3a2/0x550 [ 65.770528] [] redraw_screen+0x189/0x240 [ 65.776750] [] fbcon_blank+0x20a/0x2d0 [ 65.782778] [] ? erst_writer+0x209/0x330 [ 65.789002] [] ? internal_add_timer+0x63/0x80 [ 65.795710] [] ? mod_timer+0x127/0x1e0 [ 65.801740] [] do_unblank_screen+0xa8/0x1d0 [ 65.808255] [] unblank_screen+0x10/0x20 [ 65.814381] [] bust_spinlocks+0x19/0x40 [ 65.820508] [] panic+0x106/0x1f5 [ 65.825955] [] mce_panic+0x2ac/0x2e0 [ 65.831789] [] ? delay_tsc+0x4a/0x80 [ 65.837625] [] do_machine_check+0xbaf/0xbf0 [ 65.844138] [] ? intel_idle+0xc7/0x150 [ 65.850166] [] machine_check+0x1f/0x30 [ 65.856195] [] ? intel_idle+0xc7/0x150 [ 65.86] <> [] cpuidle_enter_state+0x55/0x170 [ 65.869823] [] cpuidle_enter+0x17/0x20 [ 65.875852] [] cpu_startup_entry+0x2d8/0x370 [ 65.882467] [] start_secondary+0x159/0x180 There's __drm_modeset_lock_all() which Daniel Vetter introduced for this purpose. We can leverage that without reinventing anything. This patch works with the latest kernel. Reviewed-by: Rob Clark Tested-by: Tony Luck Signed-off-by: Rui Wang --- Dave: I don't see this in any of your trees yet. Bug is really annoying when testing machine check code because the above stack dumps just repeat endlessly until I manually hit the reset button drivers/gpu/drm/drm_fb_helper.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 0c0c39bac23d..70dd2f4eb299 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -732,7 +732,9 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) int i, j, rc = 0; int start; - drm_modeset_lock_all(dev); + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) { + return -EBUSY; + } if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY; @@ -910,7 +912,9 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var, int ret = 0; int i; - drm_modeset_lock_all(dev); + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) { + return -EBUSY; + } if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY; -- 2.1.0
[PATCH] drm: fb helper should avoid sleeping in panic context
On Tue, Dec 09, 2014 at 08:05:21PM -0500, Rob Clark wrote: > oh, whoops.. gmail hiding quoted text.. > > yeah, that looks sane, > > Reviewed-by: Rob Clark > > On Tue, Dec 9, 2014 at 7:55 PM, rui wang wrote: > > Hi Rob, > > Yes it's exactly what I'm doing. Please scroll down and review my patch. > > > > Thanks > > Rui > > > > On 12/10/14, Rob Clark wrote: > >> perhaps fb helpers could use __drm_modeset_lock_all() w/ trylock=true > >> in panic context? > >> > >> BR, > >> -R > >> > >> On Tue, Dec 9, 2014 at 7:09 PM, rui wang wrote: > >>> Hi All, > >>> > >>> Any comment ? Or any better idea how this should be fixed? > >>> > >>> Regards, > >>> Rui > >>> Dear gmail-ers, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Please stop the top-posting or use a mail client which doesn't facilitate the idiocy. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH] drm: fb helper should avoid sleeping in panic context
Hi Rob, Yes it's exactly what I'm doing. Please scroll down and review my patch. Thanks Rui On 12/10/14, Rob Clark wrote: > perhaps fb helpers could use __drm_modeset_lock_all() w/ trylock=true > in panic context? > > BR, > -R > > On Tue, Dec 9, 2014 at 7:09 PM, rui wang wrote: >> Hi All, >> >> Any comment ? Or any better idea how this should be fixed? >> >> Regards, >> Rui >> >> -- Forwarded message -- >> From: ruiv.wang at gmail.com >> Date: Thu, 4 Dec 2014 22:11:35 +0800 >> Subject: [PATCH] drm: fb helper should avoid sleeping in panic context >> To: airlied at redhat.com, daniel.vetter at ffwll.ch, tony.luck at intel.com, >> bp at alien8.de, aris at redhat.com, rui.y.wang at intel.com >> Cc: linux-kernel at vger.kernel.org >> >> From: Rui Wang >> >> There are still some places in the fb helper that need to avoid >> sleeping in panic context. Here's an example: >> >> [ 65.615496] bad: scheduling from the idle thread! >> [ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G ME >> 3.18.0-rc4-7-default+ #20 >> >> [ 65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, >> BIOS BRHSXSD1.86B.0056.R01.1409242327 09/24/2014 >> [ 65.641923] 88087f693d80 88087f689878 81566db9 >> >> [ 65.650226] 88087f693d80 88087f689898 810871ff >> 88046eb3e0d0 >> [ 65.658527] 88087f693d80 88087f6898c8 8107c1fa >> 00017f6898b8 >> [ 65.666830] Call Trace: >> [ 65.669557] <#MC> [] dump_stack+0x46/0x58 >> [ 65.675994] [] dequeue_task_idle+0x2f/0x40 >> [ 65.682412] [] dequeue_task+0x5a/0x80 >> [ 65.688345] [] deactivate_task+0x23/0x30 >> [ 65.694569] [] __schedule+0x580/0x7f0 >> [ 65.700502] [] schedule_preempt_disabled+0x29/0x70 >> [ 65.707696] [] __ww_mutex_lock_slowpath+0xb8/0x162 >> [ 65.714891] [] __ww_mutex_lock+0x53/0x85 >> [ 65.721125] [] drm_modeset_lock+0x3d/0x110 [drm] >> [ 65.728132] [] __drm_modeset_lock_all+0x8a/0x120 >> [drm] >> [ 65.735721] [] drm_modeset_lock_all+0x10/0x30 [drm] >> [ 65.743015] [] >> drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper] >> [ 65.751857] [] fb_pan_display+0xd1/0x1a0 >> [ 65.758081] [] bit_update_start+0x20/0x50 >> [ 65.764400] [] fbcon_switch+0x3a2/0x550 >> [ 65.770528] [] redraw_screen+0x189/0x240 >> [ 65.776750] [] fbcon_blank+0x20a/0x2d0 >> [ 65.782778] [] ? erst_writer+0x209/0x330 >> [ 65.789002] [] ? internal_add_timer+0x63/0x80 >> [ 65.795710] [] ? mod_timer+0x127/0x1e0 >> [ 65.801740] [] do_unblank_screen+0xa8/0x1d0 >> [ 65.808255] [] unblank_screen+0x10/0x20 >> [ 65.814381] [] bust_spinlocks+0x19/0x40 >> [ 65.820508] [] panic+0x106/0x1f5 >> [ 65.825955] [] mce_panic+0x2ac/0x2e0 >> [ 65.831789] [] ? delay_tsc+0x4a/0x80 >> [ 65.837625] [] do_machine_check+0xbaf/0xbf0 >> [ 65.844138] [] ? intel_idle+0xc7/0x150 >> [ 65.850166] [] machine_check+0x1f/0x30 >> [ 65.856195] [] ? intel_idle+0xc7/0x150 >> [ 65.86] <> [] >> cpuidle_enter_state+0x55/0x170 >> [ 65.869823] [] cpuidle_enter+0x17/0x20 >> [ 65.875852] [] cpu_startup_entry+0x2d8/0x370 >> [ 65.882467] [] start_secondary+0x159/0x180 >> >> There's __drm_modeset_lock_all() which Daniel Vetter introduced for this >> purpose. We can leverage that without reinventing anything. This patch >> works with the latest kernel. >> >> Signed-off-by: Rui Wang >> --- >> drivers/gpu/drm/drm_fb_helper.c |8 ++-- >> 1 files changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c >> b/drivers/gpu/drm/drm_fb_helper.c >> index 0c0c39b..70dd2f4 100644 >> --- a/drivers/gpu/drm/drm_fb_helper.c >> +++ b/drivers/gpu/drm/drm_fb_helper.c >> @@ -732,7 +732,9 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, >> struct fb_info *info) >> int i, j, rc = 0; >> int start; >> >> - drm_modeset_lock_all(dev); >> + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) { >> + return -EBUSY; >> + } >> if (!drm_fb_helper_is_bound(fb_helper)) { >> drm_modeset_unlock_all(dev); >> return -EBUSY; >> @@ -910,7 +912,9 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo >> *var, >> int ret = 0; >> int i; >> >> - drm_modeset_lock_all(
[PATCH] drm: fb helper should avoid sleeping in panic context
Hi All, Any comment ? Or any better idea how this should be fixed? Regards, Rui -- Forwarded message -- From: ruiv.w...@gmail.com Date: Thu, 4 Dec 2014 22:11:35 +0800 Subject: [PATCH] drm: fb helper should avoid sleeping in panic context To: airlied at redhat.com, daniel.vetter at ffwll.ch, tony.luck at intel.com, bp at alien8.de, aris at redhat.com, rui.y.wang at intel.com Cc: linux-kernel at vger.kernel.org From: Rui Wang <rui.y.w...@intel.com> There are still some places in the fb helper that need to avoid sleeping in panic context. Here's an example: [ 65.615496] bad: scheduling from the idle thread! [ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G ME 3.18.0-rc4-7-default+ #20 [ 65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRHSXSD1.86B.0056.R01.1409242327 09/24/2014 [ 65.641923] 88087f693d80 88087f689878 81566db9 [ 65.650226] 88087f693d80 88087f689898 810871ff 88046eb3e0d0 [ 65.658527] 88087f693d80 88087f6898c8 8107c1fa 00017f6898b8 [ 65.666830] Call Trace: [ 65.669557] <#MC> [] dump_stack+0x46/0x58 [ 65.675994] [] dequeue_task_idle+0x2f/0x40 [ 65.682412] [] dequeue_task+0x5a/0x80 [ 65.688345] [] deactivate_task+0x23/0x30 [ 65.694569] [] __schedule+0x580/0x7f0 [ 65.700502] [] schedule_preempt_disabled+0x29/0x70 [ 65.707696] [] __ww_mutex_lock_slowpath+0xb8/0x162 [ 65.714891] [] __ww_mutex_lock+0x53/0x85 [ 65.721125] [] drm_modeset_lock+0x3d/0x110 [drm] [ 65.728132] [] __drm_modeset_lock_all+0x8a/0x120 [drm] [ 65.735721] [] drm_modeset_lock_all+0x10/0x30 [drm] [ 65.743015] [] drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper] [ 65.751857] [] fb_pan_display+0xd1/0x1a0 [ 65.758081] [] bit_update_start+0x20/0x50 [ 65.764400] [] fbcon_switch+0x3a2/0x550 [ 65.770528] [] redraw_screen+0x189/0x240 [ 65.776750] [] fbcon_blank+0x20a/0x2d0 [ 65.782778] [] ? erst_writer+0x209/0x330 [ 65.789002] [] ? internal_add_timer+0x63/0x80 [ 65.795710] [] ? mod_timer+0x127/0x1e0 [ 65.801740] [] do_unblank_screen+0xa8/0x1d0 [ 65.808255] [] unblank_screen+0x10/0x20 [ 65.814381] [] bust_spinlocks+0x19/0x40 [ 65.820508] [] panic+0x106/0x1f5 [ 65.825955] [] mce_panic+0x2ac/0x2e0 [ 65.831789] [] ? delay_tsc+0x4a/0x80 [ 65.837625] [] do_machine_check+0xbaf/0xbf0 [ 65.844138] [] ? intel_idle+0xc7/0x150 [ 65.850166] [] machine_check+0x1f/0x30 [ 65.856195] [] ? intel_idle+0xc7/0x150 [ 65.86] <> [] cpuidle_enter_state+0x55/0x170 [ 65.869823] [] cpuidle_enter+0x17/0x20 [ 65.875852] [] cpu_startup_entry+0x2d8/0x370 [ 65.882467] [] start_secondary+0x159/0x180 There's __drm_modeset_lock_all() which Daniel Vetter introduced for this purpose. We can leverage that without reinventing anything. This patch works with the latest kernel. Signed-off-by: Rui Wang --- drivers/gpu/drm/drm_fb_helper.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 0c0c39b..70dd2f4 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -732,7 +732,9 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) int i, j, rc = 0; int start; - drm_modeset_lock_all(dev); + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) { + return -EBUSY; + } if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY; @@ -910,7 +912,9 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var, int ret = 0; int i; - drm_modeset_lock_all(dev); + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) { + return -EBUSY; + } if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY; -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm: fb helper should avoid sleeping in panic context
oh, whoops.. gmail hiding quoted text.. yeah, that looks sane, Reviewed-by: Rob Clark On Tue, Dec 9, 2014 at 7:55 PM, rui wang wrote: > Hi Rob, > Yes it's exactly what I'm doing. Please scroll down and review my patch. > > Thanks > Rui > > On 12/10/14, Rob Clark wrote: >> perhaps fb helpers could use __drm_modeset_lock_all() w/ trylock=true >> in panic context? >> >> BR, >> -R >> >> On Tue, Dec 9, 2014 at 7:09 PM, rui wang wrote: >>> Hi All, >>> >>> Any comment ? Or any better idea how this should be fixed? >>> >>> Regards, >>> Rui >>> >>> ---------- Forwarded message -- >>> From: ruiv.wang at gmail.com >>> Date: Thu, 4 Dec 2014 22:11:35 +0800 >>> Subject: [PATCH] drm: fb helper should avoid sleeping in panic context >>> To: airlied at redhat.com, daniel.vetter at ffwll.ch, tony.luck at >>> intel.com, >>> bp at alien8.de, aris at redhat.com, rui.y.wang at intel.com >>> Cc: linux-kernel at vger.kernel.org >>> >>> From: Rui Wang >>> >>> There are still some places in the fb helper that need to avoid >>> sleeping in panic context. Here's an example: >>> >>> [ 65.615496] bad: scheduling from the idle thread! >>> [ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G ME >>> 3.18.0-rc4-7-default+ #20 >>> >>> [ 65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, >>> BIOS BRHSXSD1.86B.0056.R01.1409242327 09/24/2014 >>> [ 65.641923] 88087f693d80 88087f689878 81566db9 >>> >>> [ 65.650226] 88087f693d80 88087f689898 810871ff >>> 88046eb3e0d0 >>> [ 65.658527] 88087f693d80 88087f6898c8 8107c1fa >>> 00017f6898b8 >>> [ 65.666830] Call Trace: >>> [ 65.669557] <#MC> [] dump_stack+0x46/0x58 >>> [ 65.675994] [] dequeue_task_idle+0x2f/0x40 >>> [ 65.682412] [] dequeue_task+0x5a/0x80 >>> [ 65.688345] [] deactivate_task+0x23/0x30 >>> [ 65.694569] [] __schedule+0x580/0x7f0 >>> [ 65.700502] [] schedule_preempt_disabled+0x29/0x70 >>> [ 65.707696] [] __ww_mutex_lock_slowpath+0xb8/0x162 >>> [ 65.714891] [] __ww_mutex_lock+0x53/0x85 >>> [ 65.721125] [] drm_modeset_lock+0x3d/0x110 [drm] >>> [ 65.728132] [] __drm_modeset_lock_all+0x8a/0x120 >>> [drm] >>> [ 65.735721] [] drm_modeset_lock_all+0x10/0x30 [drm] >>> [ 65.743015] [] >>> drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper] >>> [ 65.751857] [] fb_pan_display+0xd1/0x1a0 >>> [ 65.758081] [] bit_update_start+0x20/0x50 >>> [ 65.764400] [] fbcon_switch+0x3a2/0x550 >>> [ 65.770528] [] redraw_screen+0x189/0x240 >>> [ 65.776750] [] fbcon_blank+0x20a/0x2d0 >>> [ 65.782778] [] ? erst_writer+0x209/0x330 >>> [ 65.789002] [] ? internal_add_timer+0x63/0x80 >>> [ 65.795710] [] ? mod_timer+0x127/0x1e0 >>> [ 65.801740] [] do_unblank_screen+0xa8/0x1d0 >>> [ 65.808255] [] unblank_screen+0x10/0x20 >>> [ 65.814381] [] bust_spinlocks+0x19/0x40 >>> [ 65.820508] [] panic+0x106/0x1f5 >>> [ 65.825955] [] mce_panic+0x2ac/0x2e0 >>> [ 65.831789] [] ? delay_tsc+0x4a/0x80 >>> [ 65.837625] [] do_machine_check+0xbaf/0xbf0 >>> [ 65.844138] [] ? intel_idle+0xc7/0x150 >>> [ 65.850166] [] machine_check+0x1f/0x30 >>> [ 65.856195] [] ? intel_idle+0xc7/0x150 >>> [ 65.86] <> [] >>> cpuidle_enter_state+0x55/0x170 >>> [ 65.869823] [] cpuidle_enter+0x17/0x20 >>> [ 65.875852] [] cpu_startup_entry+0x2d8/0x370 >>> [ 65.882467] [] start_secondary+0x159/0x180 >>> >>> There's __drm_modeset_lock_all() which Daniel Vetter introduced for this >>> purpose. We can leverage that without reinventing anything. This patch >>> works with the latest kernel. >>> >>> Signed-off-by: Rui Wang >>> --- >>> drivers/gpu/drm/drm_fb_helper.c |8 ++-- >>> 1 files changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c >>> b/drivers/gpu/drm/drm_fb_helper.c >>> index 0c0c39b..70dd2f4 100644 >>> --- a/drivers/gpu/drm/drm_fb_helper.c >>> +++ b/drivers/gpu/drm/drm_fb_helper.c >>> @@ -732,7 +732,9 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, >>> struct fb_info *info) >>> int i, j, rc = 0;
[PATCH] drm: fb helper should avoid sleeping in panic context
perhaps fb helpers could use __drm_modeset_lock_all() w/ trylock=true in panic context? BR, -R On Tue, Dec 9, 2014 at 7:09 PM, rui wang wrote: > Hi All, > > Any comment ? Or any better idea how this should be fixed? > > Regards, > Rui > > -- Forwarded message -- > From: ruiv.wang at gmail.com > Date: Thu, 4 Dec 2014 22:11:35 +0800 > Subject: [PATCH] drm: fb helper should avoid sleeping in panic context > To: airlied at redhat.com, daniel.vetter at ffwll.ch, tony.luck at intel.com, > bp at alien8.de, aris at redhat.com, rui.y.wang at intel.com > Cc: linux-kernel at vger.kernel.org > > From: Rui Wang > > There are still some places in the fb helper that need to avoid > sleeping in panic context. Here's an example: > > [ 65.615496] bad: scheduling from the idle thread! > [ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G ME > 3.18.0-rc4-7-default+ #20 > > [ 65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, > BIOS BRHSXSD1.86B.0056.R01.1409242327 09/24/2014 > [ 65.641923] 88087f693d80 88087f689878 81566db9 > > [ 65.650226] 88087f693d80 88087f689898 810871ff > 88046eb3e0d0 > [ 65.658527] 88087f693d80 88087f6898c8 8107c1fa > 00017f6898b8 > [ 65.666830] Call Trace: > [ 65.669557] <#MC> [] dump_stack+0x46/0x58 > [ 65.675994] [] dequeue_task_idle+0x2f/0x40 > [ 65.682412] [] dequeue_task+0x5a/0x80 > [ 65.688345] [] deactivate_task+0x23/0x30 > [ 65.694569] [] __schedule+0x580/0x7f0 > [ 65.700502] [] schedule_preempt_disabled+0x29/0x70 > [ 65.707696] [] __ww_mutex_lock_slowpath+0xb8/0x162 > [ 65.714891] [] __ww_mutex_lock+0x53/0x85 > [ 65.721125] [] drm_modeset_lock+0x3d/0x110 [drm] > [ 65.728132] [] __drm_modeset_lock_all+0x8a/0x120 [drm] > [ 65.735721] [] drm_modeset_lock_all+0x10/0x30 [drm] > [ 65.743015] [] > drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper] > [ 65.751857] [] fb_pan_display+0xd1/0x1a0 > [ 65.758081] [] bit_update_start+0x20/0x50 > [ 65.764400] [] fbcon_switch+0x3a2/0x550 > [ 65.770528] [] redraw_screen+0x189/0x240 > [ 65.776750] [] fbcon_blank+0x20a/0x2d0 > [ 65.782778] [] ? erst_writer+0x209/0x330 > [ 65.789002] [] ? internal_add_timer+0x63/0x80 > [ 65.795710] [] ? mod_timer+0x127/0x1e0 > [ 65.801740] [] do_unblank_screen+0xa8/0x1d0 > [ 65.808255] [] unblank_screen+0x10/0x20 > [ 65.814381] [] bust_spinlocks+0x19/0x40 > [ 65.820508] [] panic+0x106/0x1f5 > [ 65.825955] [] mce_panic+0x2ac/0x2e0 > [ 65.831789] [] ? delay_tsc+0x4a/0x80 > [ 65.837625] [] do_machine_check+0xbaf/0xbf0 > [ 65.844138] [] ? intel_idle+0xc7/0x150 > [ 65.850166] [] machine_check+0x1f/0x30 > [ 65.856195] [] ? intel_idle+0xc7/0x150 > [ 65.86] <> [] cpuidle_enter_state+0x55/0x170 > [ 65.869823] [] cpuidle_enter+0x17/0x20 > [ 65.875852] [] cpu_startup_entry+0x2d8/0x370 > [ 65.882467] [] start_secondary+0x159/0x180 > > There's __drm_modeset_lock_all() which Daniel Vetter introduced for this > purpose. We can leverage that without reinventing anything. This patch > works with the latest kernel. > > Signed-off-by: Rui Wang > --- > drivers/gpu/drm/drm_fb_helper.c |8 ++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 0c0c39b..70dd2f4 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -732,7 +732,9 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, > struct fb_info *info) > int i, j, rc = 0; > int start; > > - drm_modeset_lock_all(dev); > + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) { > + return -EBUSY; > + } > if (!drm_fb_helper_is_bound(fb_helper)) { > drm_modeset_unlock_all(dev); > return -EBUSY; > @@ -910,7 +912,9 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo > *var, > int ret = 0; > int i; > > - drm_modeset_lock_all(dev); > + if (__drm_modeset_lock_all(dev, !!oops_in_progress)) { > + return -EBUSY; > + } > if (!drm_fb_helper_is_bound(fb_helper)) { > drm_modeset_unlock_all(dev); > return -EBUSY; > -- > 1.7.5.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/