lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5372b72-8dc0-4f2d-ad5c-086f3e75ee81@redhat.com>
Date: Wed, 11 Feb 2026 22:54:11 +0100
From: Jocelyn Falempe <jfalempe@...hat.com>
To: mhklinux@...look.com, drawat.floss@...il.com,
 maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de,
 airlied@...il.com, simona@...ll.ch, kys@...rosoft.com,
 haiyangz@...rosoft.com, wei.liu@...nel.org, decui@...rosoft.com,
 longli@...rosoft.com, ryasuoka@...hat.com
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 linux-hyperv@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 2/2] drm/hyperv: During panic do VMBus unload after frame
 buffer is flushed

On 09/02/2026 08:02, mhkelley58@...il.com wrote:
> From: Michael Kelley <mhklinux@...look.com>
> 
> In a VM, Linux panic information (reason for the panic, stack trace,
> etc.) may be written to a serial console and/or a virtual frame buffer
> for a graphics console. The latter may need to be flushed back to the
> host hypervisor for display.
> 
> The current Hyper-V DRM driver for the frame buffer does the flushing
> *after* the VMBus connection has been unloaded, such that panic messages
> are not displayed on the graphics console. A user with a Hyper-V graphics
> console is left with just a hung empty screen after a panic. The enhanced
> control that DRM provides over the panic display in the graphics console
> is similarly non-functional.
> 
> Commit 3671f3777758 ("drm/hyperv: Add support for drm_panic") added
> the Hyper-V DRM driver support to flush the virtual frame buffer. It
> provided necessary functionality but did not handle the sequencing
> problem with VMBus unload.
> 
> Fix the full problem by using VMBus functions to suppress the VMBus
> unload that is normally done by the VMBus driver in the panic path. Then
> after the frame buffer has been flushed, do the VMBus unload so that a
> kdump kernel can start cleanly. As expected, CONFIG_DRM_PANIC must be
> selected for these changes to have effect. As a side benefit, the
> enhanced features of the DRM panic path are also functional.

Thanks for properly fixing this issue with DRM Panic on hyperv.

I've a small comment below.

With that fixed:
Reviewed-by: Jocelyn Falempe <jfalempe@...hat.com>

The first patch looks good too, I can review it if no other step up, as 
I'm not familiar with hyperv.

> 
> Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic")
> Signed-off-by: Michael Kelley <mhklinux@...look.com>
> ---
>   drivers/gpu/drm/hyperv/hyperv_drm_drv.c     |  4 ++++
>   drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 15 ++++++++-------
>   2 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> index 06b5d96e6eaf..79e51643be67 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> @@ -150,6 +150,9 @@ static int hyperv_vmbus_probe(struct hv_device *hdev,
>   		goto err_free_mmio;
>   	}
>   
> +	/* If DRM panic path is stubbed out VMBus code must do the unload */
> +	if (IS_ENABLED(CONFIG_DRM_PANIC) && IS_ENABLED(CONFIG_PRINTK))

I think drm_panic should still work without printk.
The "user" panic screen would be unaffected, but the "kmsg" screen might 
be blank, and the "qr_code" would generate an empty qr code.
(Actually I never tried to build a kernel without printk).

> +		vmbus_set_skip_unload(true);
>   	drm_client_setup(dev, NULL);
>   
>   	return 0;
> @@ -169,6 +172,7 @@ static void hyperv_vmbus_remove(struct hv_device *hdev)
>   	struct drm_device *dev = hv_get_drvdata(hdev);
>   	struct hyperv_drm_device *hv = to_hv(dev);
>   
> +	vmbus_set_skip_unload(false);
>   	drm_dev_unplug(dev);
>   	drm_atomic_helper_shutdown(dev);
>   	vmbus_close(hdev->channel);
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> index 7978f8c8108c..d48ca6c23b7c 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> @@ -212,15 +212,16 @@ static void hyperv_plane_panic_flush(struct drm_plane *plane)
>   	struct hyperv_drm_device *hv = to_hv(plane->dev);
>   	struct drm_rect rect;
>   
> -	if (!plane->state || !plane->state->fb)
> -		return;
> +	if (plane->state && plane->state->fb) {
> +		rect.x1 = 0;
> +		rect.y1 = 0;
> +		rect.x2 = plane->state->fb->width;
> +		rect.y2 = plane->state->fb->height;
>   
> -	rect.x1 = 0;
> -	rect.y1 = 0;
> -	rect.x2 = plane->state->fb->width;
> -	rect.y2 = plane->state->fb->height;
> +		hyperv_update_dirt(hv->hdev, &rect);
> +	}
>   
> -	hyperv_update_dirt(hv->hdev, &rect);
> +	vmbus_initiate_unload(true);
>   }
>   
>   static const struct drm_plane_helper_funcs hyperv_plane_helper_funcs = {

-- 

Jocelyn


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ