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
