* [PATCH] drm: fb helper should avoid sleeping in panic context
@ 2014-12-04 14:11 ruiv.wang
2014-12-05 12:40 ` rui wang
2014-12-10 0:09 ` rui wang
0 siblings, 2 replies; 8+ messages in thread
From: ruiv.wang @ 2014-12-04 14:11 UTC (permalink / raw)
To: airlied, daniel.vetter, tony.luck, bp, aris, rui.y.wang; +Cc: linux-kernel
From: Rui Wang <rui.y.wang@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 M E 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] ffff88087f693d80 ffff88087f689878 ffffffff81566db9 0000000000000000
[ 65.650226] ffff88087f693d80 ffff88087f689898 ffffffff810871ff ffff88046eb3e0d0
[ 65.658527] ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa 000000017f6898b8
[ 65.666830] Call Trace:
[ 65.669557] <#MC> [<ffffffff81566db9>] dump_stack+0x46/0x58
[ 65.675994] [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
[ 65.682412] [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
[ 65.688345] [<ffffffff810804f3>] deactivate_task+0x23/0x30
[ 65.694569] [<ffffffff81569050>] __schedule+0x580/0x7f0
[ 65.700502] [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
[ 65.707696] [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
[ 65.714891] [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
[ 65.721125] [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
[ 65.728132] [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120 [drm]
[ 65.735721] [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
[ 65.743015] [<ffffffffa01af8bf>] drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
[ 65.751857] [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
[ 65.758081] [<ffffffff81326010>] bit_update_start+0x20/0x50
[ 65.764400] [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
[ 65.770528] [<ffffffff813a01c9>] redraw_screen+0x189/0x240
[ 65.776750] [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
[ 65.782778] [<ffffffff8137d359>] ? erst_writer+0x209/0x330
[ 65.789002] [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
[ 65.795710] [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
[ 65.801740] [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
[ 65.808255] [<ffffffff813a0e10>] unblank_screen+0x10/0x20
[ 65.814381] [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
[ 65.820508] [<ffffffff81561ca7>] panic+0x106/0x1f5
[ 65.825955] [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
[ 65.831789] [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
[ 65.837625] [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
[ 65.844138] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[ 65.850166] [<ffffffff8156f03f>] machine_check+0x1f/0x30
[ 65.856195] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[ 65.862222] <<EOE>> [<ffffffff814283d5>] cpuidle_enter_state+0x55/0x170
[ 65.869823] [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
[ 65.875852] [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
[ 65.882467] [<ffffffff8102fe29>] 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 <rui.y.wang@intel.com>
---
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm: fb helper should avoid sleeping in panic context
2014-12-04 14:11 [PATCH] drm: fb helper should avoid sleeping in panic context ruiv.wang
@ 2014-12-05 12:40 ` rui wang
2014-12-10 0:09 ` rui wang
1 sibling, 0 replies; 8+ messages in thread
From: rui wang @ 2014-12-05 12:40 UTC (permalink / raw)
To: airlied, daniel.vetter, tony.luck, bp, aris, rui.y.wang; +Cc: linux-kernel
BTW, the impact of this bug is that the panic cannot reboot the
machine and it prints an infinite stream of the error messages. The
panic goes on forever because there's a for(;;) loop in
__mutex_lock_common(), so we enter __schedule() again and again.
Thanks
Rui
On 12/4/14, ruiv.wang@gmail.com <ruiv.wang@gmail.com> wrote:
> From: Rui Wang <rui.y.wang@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 M E
> 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] ffff88087f693d80 ffff88087f689878 ffffffff81566db9
> 0000000000000000
> [ 65.650226] ffff88087f693d80 ffff88087f689898 ffffffff810871ff
> ffff88046eb3e0d0
> [ 65.658527] ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa
> 000000017f6898b8
> [ 65.666830] Call Trace:
> [ 65.669557] <#MC> [<ffffffff81566db9>] dump_stack+0x46/0x58
> [ 65.675994] [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
> [ 65.682412] [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
> [ 65.688345] [<ffffffff810804f3>] deactivate_task+0x23/0x30
> [ 65.694569] [<ffffffff81569050>] __schedule+0x580/0x7f0
> [ 65.700502] [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
> [ 65.707696] [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
> [ 65.714891] [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
> [ 65.721125] [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
> [ 65.728132] [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120
> [drm]
> [ 65.735721] [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
> [ 65.743015] [<ffffffffa01af8bf>] drm_fb_helper_pan_display+0x2f/0xf0
> [drm_kms_helper]
> [ 65.751857] [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
> [ 65.758081] [<ffffffff81326010>] bit_update_start+0x20/0x50
> [ 65.764400] [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
> [ 65.770528] [<ffffffff813a01c9>] redraw_screen+0x189/0x240
> [ 65.776750] [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
> [ 65.782778] [<ffffffff8137d359>] ? erst_writer+0x209/0x330
> [ 65.789002] [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
> [ 65.795710] [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
> [ 65.801740] [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
> [ 65.808255] [<ffffffff813a0e10>] unblank_screen+0x10/0x20
> [ 65.814381] [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
> [ 65.820508] [<ffffffff81561ca7>] panic+0x106/0x1f5
> [ 65.825955] [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
> [ 65.831789] [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
> [ 65.837625] [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
> [ 65.844138] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
> [ 65.850166] [<ffffffff8156f03f>] machine_check+0x1f/0x30
> [ 65.856195] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
> [ 65.862222] <<EOE>> [<ffffffff814283d5>]
> cpuidle_enter_state+0x55/0x170
> [ 65.869823] [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
> [ 65.875852] [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
> [ 65.882467] [<ffffffff8102fe29>] 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 <rui.y.wang@intel.com>
> ---
> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] drm: fb helper should avoid sleeping in panic context
2014-12-04 14:11 [PATCH] drm: fb helper should avoid sleeping in panic context ruiv.wang
2014-12-05 12:40 ` rui wang
@ 2014-12-10 0:09 ` rui wang
2014-12-10 0:51 ` Rob Clark
1 sibling, 1 reply; 8+ messages in thread
From: rui wang @ 2014-12-10 0:09 UTC (permalink / raw)
To: airlied, daniel.vetter, tony.luck, bp, aris, rui.y.wang
Cc: dri-devel, linux-kernel
Hi All,
Any comment ? Or any better idea how this should be fixed?
Regards,
Rui
---------- Forwarded message ----------
From: ruiv.wang@gmail.com
Date: Thu, 4 Dec 2014 22:11:35 +0800
Subject: [PATCH] drm: fb helper should avoid sleeping in panic context
To: airlied@redhat.com, daniel.vetter@ffwll.ch, tony.luck@intel.com,
bp@alien8.de, aris@redhat.com, rui.y.wang@intel.com
Cc: linux-kernel@vger.kernel.org
From: Rui Wang <rui.y.wang@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 M E
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] ffff88087f693d80 ffff88087f689878 ffffffff81566db9
0000000000000000
[ 65.650226] ffff88087f693d80 ffff88087f689898 ffffffff810871ff
ffff88046eb3e0d0
[ 65.658527] ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa
000000017f6898b8
[ 65.666830] Call Trace:
[ 65.669557] <#MC> [<ffffffff81566db9>] dump_stack+0x46/0x58
[ 65.675994] [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
[ 65.682412] [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
[ 65.688345] [<ffffffff810804f3>] deactivate_task+0x23/0x30
[ 65.694569] [<ffffffff81569050>] __schedule+0x580/0x7f0
[ 65.700502] [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
[ 65.707696] [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
[ 65.714891] [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
[ 65.721125] [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
[ 65.728132] [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120 [drm]
[ 65.735721] [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
[ 65.743015] [<ffffffffa01af8bf>]
drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
[ 65.751857] [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
[ 65.758081] [<ffffffff81326010>] bit_update_start+0x20/0x50
[ 65.764400] [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
[ 65.770528] [<ffffffff813a01c9>] redraw_screen+0x189/0x240
[ 65.776750] [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
[ 65.782778] [<ffffffff8137d359>] ? erst_writer+0x209/0x330
[ 65.789002] [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
[ 65.795710] [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
[ 65.801740] [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
[ 65.808255] [<ffffffff813a0e10>] unblank_screen+0x10/0x20
[ 65.814381] [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
[ 65.820508] [<ffffffff81561ca7>] panic+0x106/0x1f5
[ 65.825955] [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
[ 65.831789] [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
[ 65.837625] [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
[ 65.844138] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[ 65.850166] [<ffffffff8156f03f>] machine_check+0x1f/0x30
[ 65.856195] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[ 65.862222] <<EOE>> [<ffffffff814283d5>] cpuidle_enter_state+0x55/0x170
[ 65.869823] [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
[ 65.875852] [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
[ 65.882467] [<ffffffff8102fe29>] 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 <rui.y.wang@intel.com>
---
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm: fb helper should avoid sleeping in panic context
2014-12-10 0:09 ` rui wang
@ 2014-12-10 0:51 ` Rob Clark
2014-12-10 0:55 ` rui wang
0 siblings, 1 reply; 8+ messages in thread
From: Rob Clark @ 2014-12-10 0:51 UTC (permalink / raw)
To: rui wang
Cc: airlied, Daniel Vetter, tony.luck, bp, aris, rui.y.wang,
dri-devel, Linux Kernel Mailing List
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 <ruiv.wang@gmail.com> wrote:
> Hi All,
>
> Any comment ? Or any better idea how this should be fixed?
>
> Regards,
> Rui
>
> ---------- Forwarded message ----------
> From: ruiv.wang@gmail.com
> Date: Thu, 4 Dec 2014 22:11:35 +0800
> Subject: [PATCH] drm: fb helper should avoid sleeping in panic context
> To: airlied@redhat.com, daniel.vetter@ffwll.ch, tony.luck@intel.com,
> bp@alien8.de, aris@redhat.com, rui.y.wang@intel.com
> Cc: linux-kernel@vger.kernel.org
>
> From: Rui Wang <rui.y.wang@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 M E
> 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] ffff88087f693d80 ffff88087f689878 ffffffff81566db9
> 0000000000000000
> [ 65.650226] ffff88087f693d80 ffff88087f689898 ffffffff810871ff
> ffff88046eb3e0d0
> [ 65.658527] ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa
> 000000017f6898b8
> [ 65.666830] Call Trace:
> [ 65.669557] <#MC> [<ffffffff81566db9>] dump_stack+0x46/0x58
> [ 65.675994] [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
> [ 65.682412] [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
> [ 65.688345] [<ffffffff810804f3>] deactivate_task+0x23/0x30
> [ 65.694569] [<ffffffff81569050>] __schedule+0x580/0x7f0
> [ 65.700502] [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
> [ 65.707696] [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
> [ 65.714891] [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
> [ 65.721125] [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
> [ 65.728132] [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120 [drm]
> [ 65.735721] [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
> [ 65.743015] [<ffffffffa01af8bf>]
> drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
> [ 65.751857] [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
> [ 65.758081] [<ffffffff81326010>] bit_update_start+0x20/0x50
> [ 65.764400] [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
> [ 65.770528] [<ffffffff813a01c9>] redraw_screen+0x189/0x240
> [ 65.776750] [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
> [ 65.782778] [<ffffffff8137d359>] ? erst_writer+0x209/0x330
> [ 65.789002] [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
> [ 65.795710] [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
> [ 65.801740] [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
> [ 65.808255] [<ffffffff813a0e10>] unblank_screen+0x10/0x20
> [ 65.814381] [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
> [ 65.820508] [<ffffffff81561ca7>] panic+0x106/0x1f5
> [ 65.825955] [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
> [ 65.831789] [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
> [ 65.837625] [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
> [ 65.844138] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
> [ 65.850166] [<ffffffff8156f03f>] machine_check+0x1f/0x30
> [ 65.856195] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
> [ 65.862222] <<EOE>> [<ffffffff814283d5>] cpuidle_enter_state+0x55/0x170
> [ 65.869823] [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
> [ 65.875852] [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
> [ 65.882467] [<ffffffff8102fe29>] 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 <rui.y.wang@intel.com>
> ---
> 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@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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm: fb helper should avoid sleeping in panic context
2014-12-10 0:51 ` Rob Clark
@ 2014-12-10 0:55 ` rui wang
2014-12-10 1:05 ` Rob Clark
0 siblings, 1 reply; 8+ messages in thread
From: rui wang @ 2014-12-10 0:55 UTC (permalink / raw)
To: Rob Clark
Cc: airlied, Daniel Vetter, tony.luck, bp, aris, rui.y.wang,
dri-devel, Linux Kernel Mailing List
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 <robdclark@gmail.com> 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 <ruiv.wang@gmail.com> wrote:
>> Hi All,
>>
>> Any comment ? Or any better idea how this should be fixed?
>>
>> Regards,
>> Rui
>>
>> ---------- Forwarded message ----------
>> From: ruiv.wang@gmail.com
>> Date: Thu, 4 Dec 2014 22:11:35 +0800
>> Subject: [PATCH] drm: fb helper should avoid sleeping in panic context
>> To: airlied@redhat.com, daniel.vetter@ffwll.ch, tony.luck@intel.com,
>> bp@alien8.de, aris@redhat.com, rui.y.wang@intel.com
>> Cc: linux-kernel@vger.kernel.org
>>
>> From: Rui Wang <rui.y.wang@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 M E
>> 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] ffff88087f693d80 ffff88087f689878 ffffffff81566db9
>> 0000000000000000
>> [ 65.650226] ffff88087f693d80 ffff88087f689898 ffffffff810871ff
>> ffff88046eb3e0d0
>> [ 65.658527] ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa
>> 000000017f6898b8
>> [ 65.666830] Call Trace:
>> [ 65.669557] <#MC> [<ffffffff81566db9>] dump_stack+0x46/0x58
>> [ 65.675994] [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
>> [ 65.682412] [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
>> [ 65.688345] [<ffffffff810804f3>] deactivate_task+0x23/0x30
>> [ 65.694569] [<ffffffff81569050>] __schedule+0x580/0x7f0
>> [ 65.700502] [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
>> [ 65.707696] [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
>> [ 65.714891] [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
>> [ 65.721125] [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
>> [ 65.728132] [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120
>> [drm]
>> [ 65.735721] [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
>> [ 65.743015] [<ffffffffa01af8bf>]
>> drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
>> [ 65.751857] [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
>> [ 65.758081] [<ffffffff81326010>] bit_update_start+0x20/0x50
>> [ 65.764400] [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
>> [ 65.770528] [<ffffffff813a01c9>] redraw_screen+0x189/0x240
>> [ 65.776750] [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
>> [ 65.782778] [<ffffffff8137d359>] ? erst_writer+0x209/0x330
>> [ 65.789002] [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
>> [ 65.795710] [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
>> [ 65.801740] [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
>> [ 65.808255] [<ffffffff813a0e10>] unblank_screen+0x10/0x20
>> [ 65.814381] [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
>> [ 65.820508] [<ffffffff81561ca7>] panic+0x106/0x1f5
>> [ 65.825955] [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
>> [ 65.831789] [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
>> [ 65.837625] [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
>> [ 65.844138] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
>> [ 65.850166] [<ffffffff8156f03f>] machine_check+0x1f/0x30
>> [ 65.856195] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
>> [ 65.862222] <<EOE>> [<ffffffff814283d5>]
>> cpuidle_enter_state+0x55/0x170
>> [ 65.869823] [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
>> [ 65.875852] [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
>> [ 65.882467] [<ffffffff8102fe29>] 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 <rui.y.wang@intel.com>
>> ---
>> 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@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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm: fb helper should avoid sleeping in panic context
2014-12-10 0:55 ` rui wang
@ 2014-12-10 1:05 ` Rob Clark
2014-12-10 20:19 ` Borislav Petkov
2014-12-15 19:28 ` Luck, Tony
0 siblings, 2 replies; 8+ messages in thread
From: Rob Clark @ 2014-12-10 1:05 UTC (permalink / raw)
To: rui wang
Cc: airlied, Daniel Vetter, tony.luck, bp, aris, rui.y.wang,
dri-devel, Linux Kernel Mailing List
oh, whoops.. gmail hiding quoted text..
yeah, that looks sane,
Reviewed-by: Rob Clark <robdclark@gmail.com>
On Tue, Dec 9, 2014 at 7:55 PM, rui wang <ruiv.wang@gmail.com> 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 <robdclark@gmail.com> 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 <ruiv.wang@gmail.com> wrote:
>>> Hi All,
>>>
>>> Any comment ? Or any better idea how this should be fixed?
>>>
>>> Regards,
>>> Rui
>>>
>>> ---------- Forwarded message ----------
>>> From: ruiv.wang@gmail.com
>>> Date: Thu, 4 Dec 2014 22:11:35 +0800
>>> Subject: [PATCH] drm: fb helper should avoid sleeping in panic context
>>> To: airlied@redhat.com, daniel.vetter@ffwll.ch, tony.luck@intel.com,
>>> bp@alien8.de, aris@redhat.com, rui.y.wang@intel.com
>>> Cc: linux-kernel@vger.kernel.org
>>>
>>> From: Rui Wang <rui.y.wang@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 M E
>>> 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] ffff88087f693d80 ffff88087f689878 ffffffff81566db9
>>> 0000000000000000
>>> [ 65.650226] ffff88087f693d80 ffff88087f689898 ffffffff810871ff
>>> ffff88046eb3e0d0
>>> [ 65.658527] ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa
>>> 000000017f6898b8
>>> [ 65.666830] Call Trace:
>>> [ 65.669557] <#MC> [<ffffffff81566db9>] dump_stack+0x46/0x58
>>> [ 65.675994] [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
>>> [ 65.682412] [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
>>> [ 65.688345] [<ffffffff810804f3>] deactivate_task+0x23/0x30
>>> [ 65.694569] [<ffffffff81569050>] __schedule+0x580/0x7f0
>>> [ 65.700502] [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
>>> [ 65.707696] [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
>>> [ 65.714891] [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
>>> [ 65.721125] [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
>>> [ 65.728132] [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120
>>> [drm]
>>> [ 65.735721] [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
>>> [ 65.743015] [<ffffffffa01af8bf>]
>>> drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
>>> [ 65.751857] [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
>>> [ 65.758081] [<ffffffff81326010>] bit_update_start+0x20/0x50
>>> [ 65.764400] [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
>>> [ 65.770528] [<ffffffff813a01c9>] redraw_screen+0x189/0x240
>>> [ 65.776750] [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
>>> [ 65.782778] [<ffffffff8137d359>] ? erst_writer+0x209/0x330
>>> [ 65.789002] [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
>>> [ 65.795710] [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
>>> [ 65.801740] [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
>>> [ 65.808255] [<ffffffff813a0e10>] unblank_screen+0x10/0x20
>>> [ 65.814381] [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
>>> [ 65.820508] [<ffffffff81561ca7>] panic+0x106/0x1f5
>>> [ 65.825955] [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
>>> [ 65.831789] [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
>>> [ 65.837625] [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
>>> [ 65.844138] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
>>> [ 65.850166] [<ffffffff8156f03f>] machine_check+0x1f/0x30
>>> [ 65.856195] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
>>> [ 65.862222] <<EOE>> [<ffffffff814283d5>]
>>> cpuidle_enter_state+0x55/0x170
>>> [ 65.869823] [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
>>> [ 65.875852] [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
>>> [ 65.882467] [<ffffffff8102fe29>] 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 <rui.y.wang@intel.com>
>>> ---
>>> 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@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@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm: fb helper should avoid sleeping in panic context
2014-12-10 1:05 ` Rob Clark
@ 2014-12-10 20:19 ` Borislav Petkov
2014-12-15 19:28 ` Luck, Tony
1 sibling, 0 replies; 8+ messages in thread
From: Borislav Petkov @ 2014-12-10 20:19 UTC (permalink / raw)
To: Rob Clark, rui wang
Cc: airlied, Daniel Vetter, tony.luck, aris, rui.y.wang, dri-devel,
Linux Kernel Mailing List
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 <robdclark@gmail.com>
>
> On Tue, Dec 9, 2014 at 7:55 PM, rui wang <ruiv.wang@gmail.com> 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 <robdclark@gmail.com> 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 <ruiv.wang@gmail.com> 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.
--
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] drm: fb helper should avoid sleeping in panic context
2014-12-10 1:05 ` Rob Clark
2014-12-10 20:19 ` Borislav Petkov
@ 2014-12-15 19:28 ` Luck, Tony
1 sibling, 0 replies; 8+ messages in thread
From: Luck, Tony @ 2014-12-15 19:28 UTC (permalink / raw)
To: airlied
Cc: rui wang, Daniel Vetter, tony.luck, bp, aris, rui.y.wang,
dri-devel, Linux Kernel Mailing List
From: Rui Wang <rui.y.wang@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 M E 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] ffff88087f693d80 ffff88087f689878 ffffffff81566db9 0000000000000000
[ 65.650226] ffff88087f693d80 ffff88087f689898 ffffffff810871ff ffff88046eb3e0d0
[ 65.658527] ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa 000000017f6898b8
[ 65.666830] Call Trace:
[ 65.669557] <#MC> [<ffffffff81566db9>] dump_stack+0x46/0x58
[ 65.675994] [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
[ 65.682412] [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
[ 65.688345] [<ffffffff810804f3>] deactivate_task+0x23/0x30
[ 65.694569] [<ffffffff81569050>] __schedule+0x580/0x7f0
[ 65.700502] [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
[ 65.707696] [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
[ 65.714891] [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
[ 65.721125] [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
[ 65.728132] [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120 [drm]
[ 65.735721] [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
[ 65.743015] [<ffffffffa01af8bf>] drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
[ 65.751857] [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
[ 65.758081] [<ffffffff81326010>] bit_update_start+0x20/0x50
[ 65.764400] [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
[ 65.770528] [<ffffffff813a01c9>] redraw_screen+0x189/0x240
[ 65.776750] [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
[ 65.782778] [<ffffffff8137d359>] ? erst_writer+0x209/0x330
[ 65.789002] [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
[ 65.795710] [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
[ 65.801740] [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
[ 65.808255] [<ffffffff813a0e10>] unblank_screen+0x10/0x20
[ 65.814381] [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
[ 65.820508] [<ffffffff81561ca7>] panic+0x106/0x1f5
[ 65.825955] [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
[ 65.831789] [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
[ 65.837625] [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
[ 65.844138] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[ 65.850166] [<ffffffff8156f03f>] machine_check+0x1f/0x30
[ 65.856195] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[ 65.862222] <<EOE>> [<ffffffff814283d5>] cpuidle_enter_state+0x55/0x170
[ 65.869823] [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
[ 65.875852] [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
[ 65.882467] [<ffffffff8102fe29>] 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 <robdclark@gmail.com>
Tested-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rui Wang <rui.y.wang@intel.com>
---
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-12-15 19:28 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-04 14:11 [PATCH] drm: fb helper should avoid sleeping in panic context ruiv.wang
2014-12-05 12:40 ` rui wang
2014-12-10 0:09 ` rui wang
2014-12-10 0:51 ` Rob Clark
2014-12-10 0:55 ` rui wang
2014-12-10 1:05 ` Rob Clark
2014-12-10 20:19 ` Borislav Petkov
2014-12-15 19:28 ` Luck, Tony
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome