mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH AUTOSEL 6.10 01/16] drm/fb-helper: Don't schedule_work() to flush frame buffer during panic()
@ 2024-08-05 17:55 Sasha Levin
  2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 02/16] drm: panel-orientation-quirks: Add quirk for OrangePi Neo Sasha Levin
                   ` (14 more replies)
  0 siblings, 15 replies; 16+ messages in thread
From: Sasha Levin @ 2024-08-05 17:55 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Qiuxu Zhuo, Thomas Zimmermann, Yudong Wang, Maarten, Lankhorst,
	maarten.lankhorst, Sasha Levin, mripard, airlied, daniel,
	dri-devel

From: Qiuxu Zhuo <qiuxu.zhuo@intel.com>

[ Upstream commit 833cd3e9ad8360785b6c23c82dd3856df00732d9 ]

Sometimes the system [1] hangs on x86 I/O machine checks. However, the
expected behavior is to reboot the system, as the machine check handler
ultimately triggers a panic(), initiating a reboot in the last step.

The root cause is that sometimes the panic() is blocked when
drm_fb_helper_damage() invoking schedule_work() to flush the frame buffer.
This occurs during the process of flushing all messages to the frame
buffer driver as shown in the following call trace:

  Machine check occurs [2]:
    panic()
      console_flush_on_panic()
        console_flush_all()
          console_emit_next_record()
            con->write()
              vt_console_print()
                hide_cursor()
                  vc->vc_sw->con_cursor()
                    fbcon_cursor()
                      ops->cursor()
                        bit_cursor()
                          soft_cursor()
                            info->fbops->fb_imageblit()
                              drm_fbdev_generic_defio_imageblit()
                                drm_fb_helper_damage_area()
                                  drm_fb_helper_damage()
                                    schedule_work() // <--- blocked here
    ...
    emergency_restart()  // wasn't invoked, so no reboot.

During panic(), except the panic CPU, all the other CPUs are stopped.
In schedule_work(), the panic CPU requires the lock of worker_pool to
queue the work on that pool, while the lock may have been token by some
other stopped CPU. So schedule_work() is blocked.

Additionally, during a panic(), since there is no opportunity to execute
any scheduled work, it's safe to fix this issue by skipping schedule_work()
on 'oops_in_progress' in drm_fb_helper_damage().

[1] Enable the kernel option CONFIG_FRAMEBUFFER_CONSOLE,
    CONFIG_DRM_FBDEV_EMULATION, and boot with the 'console=tty0'
    kernel command line parameter.

[2] Set 'panic_timeout' to a non-zero value before calling panic().

Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: Yudong Wang <yudong.wang@intel.com>
Tested-by: Yudong Wang <yudong.wang@intel.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240703141737.75378-1-qiuxu.zhuo@intel.com
Signed-off-by: Maarten Lankhorst,,, <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/drm_fb_helper.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 117237d3528bd..618b045230336 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -631,6 +631,17 @@ static void drm_fb_helper_add_damage_clip(struct drm_fb_helper *helper, u32 x, u
 static void drm_fb_helper_damage(struct drm_fb_helper *helper, u32 x, u32 y,
 				 u32 width, u32 height)
 {
+	/*
+	 * This function may be invoked by panic() to flush the frame
+	 * buffer, where all CPUs except the panic CPU are stopped.
+	 * During the following schedule_work(), the panic CPU needs
+	 * the worker_pool lock, which might be held by a stopped CPU,
+	 * causing schedule_work() and panic() to block. Return early on
+	 * oops_in_progress to prevent this blocking.
+	 */
+	if (oops_in_progress)
+		return;
+
 	drm_fb_helper_add_damage_clip(helper, x, y, width, height);
 
 	schedule_work(&helper->damage_work);
-- 
2.43.0


^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2024-08-05 17:57 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-08-05 17:55 [PATCH AUTOSEL 6.10 01/16] drm/fb-helper: Don't schedule_work() to flush frame buffer during panic() Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 02/16] drm: panel-orientation-quirks: Add quirk for OrangePi Neo Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 03/16] scsi: ufs: core: Check LSDBS cap when !mcq Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 04/16] scsi: ufs: core: Bypass quick recovery if force reset is needed Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 05/16] btrfs: tree-checker: validate dref root and objectid Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 06/16] ALSA: hda/generic: Add a helper to mute speakers at suspend/shutdown Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 07/16] ALSA: hda/conexant: Mute speakers at suspend / shutdown Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 08/16] Input: MT - limit max slots Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 09/16] x86/CPU/AMD: Add models 0x60-0x6f to the Zen5 range Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 10/16] ALSA: ump: Transmit RPN/NRPN message at each MSB/LSB data reception Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 11/16] ALSA: ump: Explicitly reset RPN with Null RPN Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 12/16] ALSA: seq: ump: Use the common RPN/bank conversion context Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 13/16] ALSA: seq: ump: Transmit RPN/NRPN message at each MSB/LSB data reception Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 14/16] ALSA: seq: ump: Explicitly reset RPN with Null RPN Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 15/16] net/mlx5: DR, Fix 'stack guard page was hit' error in dr_rule Sasha Levin
2024-08-05 17:55 ` [PATCH AUTOSEL 6.10 16/16] smb: client: fix FSCTL_GET_REPARSE_POINT against NetApp Sasha Levin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®