Re: [PATCH 08/12] drm/panic: Split draw_panic_plane()

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] The `panic_type` parameter in `draw_panic_plane()` is ignored and shadowed by the global `drm_panic_type` variable.

Pre-existing issues:
- [High] Data race on global variables (`panic_msg`, `qrbuf1`, `qrbuf2`, `stream`) when triggering panic debugfs interface concurrently across multiple DRM devices.
--

--- Patch [8]: [PATCH 08/12] drm/panic: Split draw_panic_plane() ---
commit 87af97baf7c5108af8275ef63007ab9f483466ca
Author: Thomas Zimmermann <[email protected]>

drm/panic: Split draw_panic_plane()
    
Move locking and parameters from draw_panic_plane() into the new
helper drm_panic_display_panic_screen(). Call draw_panic_plane() from
there. The new helper is now the DRM core's interface for displaying a
panic screen.

> diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
> index 0960750bfce25..2263a11efdf63 100644
> --- a/drivers/gpu/drm/drm_panic.c
> +++ b/drivers/gpu/drm/drm_panic.c
> @@ -940,38 +940,21 @@ static void drm_panic_clear_description(void)
>  	desc_line->txt = NULL;
>  }
>  
> -static void draw_panic_plane(struct drm_plane *plane, const char *description)
> +static void draw_panic_plane(struct drm_plane *plane, const char *description,
> +			     enum drm_panic_type panic_type, u32 fg_color, u32 bg_color,
> +			     unsigned int qr_version)
>  {

[Severity: Medium]
Does this function ignore the new panic_type parameter?

The parameter is passed to draw_panic_plane(), but if the code still uses the
global drm_panic_type variable internally when calling draw_panic_dispatch():

	ret = draw_panic_dispatch(&sb, drm_panic_type, fg_color, bg_color, qr_version);

Any caller passing a specific panic_type will have its request overridden by
the global module parameter, which seems to break the intent of making this a
generic helper.

[ ... ]

> @@ -1021,7 +1027,7 @@ static ssize_t debugfs_trigger_write(struct file *file, const char __user *user_
>  	if (kstrtobool_from_user(user_buf, count, &run) == 0 && run) {
>  		struct drm_plane *plane = file->private_data;
>  
> -		draw_panic_plane(plane, "Test from debugfs");
> +		drm_panic_display_panic_screen(plane, "Test from debugfs");

[Severity: High]
This is a pre-existing issue, but does this debugfs entry point allow a data
race on global variables across different DRM devices?

When a user writes concurrently to the debugfs files of two or more distinct
DRM devices, the debugfs_trigger_write() handler acquires a per-device lock
via drm_panic_trylock().

However, these concurrent writes can proceed to mutate the unprotected global
panic_msg array in drm_panic_set_description():

	struct drm_panic_line *desc_line = &panic_msg[panic_msg_lines - 1];
	desc_line->txt = description;

This could also affect other globals like qrbuf1, qrbuf2, and the zlib
stream workspace.

Could this concurrent execution across different DRM devices corrupt memory
and lead to an inconsistent state?

>  	}
>  	return count;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=8