The state readout documentation now states that a driver should return an error when the hardware was programmed with a configuration it cannot represent, so that the state initialization falls back to the regular path.
However, a readout can also succeed with objects that cannot be fully reconstructed. The framebuffer the firmware left in the hardware was allocated outside of the kernel memory allocator, so drivers won't have any GEM object to attach to its planes. drm_fb_dma_get_scanout_buffer() dereferences the GEM object of the first plane to fill the scanout buffer description used by drm_panic, and would thus crash during a panic happening before userspace had a chance to replace the framebuffer read out from the hardware state. Return -ENODEV for such framebuffers, like we already do for imported buffers that are not accessible from the CPU. Signed-off-by: Maxime Ripard <[email protected]> --- Cc: Jocelyn Falempe <[email protected]> --- drivers/gpu/drm/drm_fb_dma_helper.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c b/drivers/gpu/drm/drm_fb_dma_helper.c index fd71969d2fb1..3a37253ab9f8 100644 --- a/drivers/gpu/drm/drm_fb_dma_helper.c +++ b/drivers/gpu/drm/drm_fb_dma_helper.c @@ -180,4 +180,12 @@ int drm_fb_dma_get_scanout_buffer(struct drm_plane *plane, dma_obj = drm_fb_dma_get_gem_obj(fb, 0); + /* + * The framebuffer has no GEM object backing its first plane, + * like a framebuffer reconstructed from a hardware state + * readout: we cannot access its contents. + */ + if (!dma_obj) + return -ENODEV; + /* Buffer should be accessible from the CPU */ if (drm_gem_is_imported(&dma_obj->base)) -- 2.55.0
