From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm: rcar-du: Don't leak device_link to CMM
Date: Wed, 25 Mar 2026 07:42:40 +1000 [thread overview]
Message-ID: <review-patch4-20260323164526.2292491-5-laurent.pinchart+renesas@ideasonboard.com> (raw)
In-Reply-To: <20260323164526.2292491-5-laurent.pinchart+renesas@ideasonboard.com>
Patch Review
**Status: Bug — NULL pointer dereference**
The core idea is sound: introduce `struct rcar_du_cmm` to group the device and link, and delete links at cleanup. However, this patch introduces a NULL pointer dereference.
In `rcar_du_crtc_create()`, `rcrtc->cmm` is only assigned when the CMM device exists:
```c
if (rcdu->cmms[swindex].dev) {
rcrtc->cmm = &rcdu->cmms[swindex];
...
}
```
If CMM is not available for a CRTC, `rcrtc->cmm` remains **NULL**. But the patch changes checks from `if (!rcrtc->cmm)` to `if (!rcrtc->cmm->dev)` in three places (`rcar_du_cmm_setup`, `rcar_du_crtc_stop`, `rcar_du_crtc_atomic_enable`), which will dereference the NULL pointer:
```c
// rcar_du_crtc.c, rcar_du_cmm_setup():
if (!rcrtc->cmm->dev) // BUG: rcrtc->cmm is NULL when no CMM
return;
// rcar_du_crtc.c, rcar_du_crtc_stop():
if (rcrtc->cmm->dev) // BUG: same issue
rcar_cmm_disable(rcrtc->cmm->dev);
// rcar_du_crtc.c, rcar_du_crtc_atomic_enable():
if (rcrtc->cmm->dev) // BUG: same issue
rcar_cmm_enable(rcrtc->cmm->dev);
```
**Fix options:**
1. Always set `rcrtc->cmm = &rcdu->cmms[swindex]` (even when `.dev` is NULL), so the pointer is always valid and only `.dev` needs checking. This is the simplest fix.
2. Add a two-level NULL check: `if (rcrtc->cmm && rcrtc->cmm->dev)` — but this is ugly and defeats the purpose of the refactoring.
Option 1 would look like:
```c
/* In rcar_du_crtc_create(): */
rcrtc->cmm = &rcdu->cmms[swindex];
if (rcrtc->cmm->dev) {
rgrp->cmms_mask |= BIT(hwindex % 2);
drm_mode_crtc_set_gamma_size(crtc, CM2_LUT_SIZE);
drm_crtc_enable_color_mgmt(crtc, 0, false, CM2_LUT_SIZE);
}
```
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-03-24 21:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 16:45 [PATCH v2 0/4] drm: rcar-du: Improve device_link handling Laurent Pinchart
2026-03-23 16:45 ` [PATCH v2 1/4] drm: rcar-du: Ensure correct suspend/resume ordering with VSP Laurent Pinchart
2026-03-24 21:42 ` Claude review: " Claude Code Review Bot
2026-03-23 16:45 ` [PATCH v2 2/4] drm: rcar-du: Store CMM device pointer instead of platform_device Laurent Pinchart
2026-03-24 21:42 ` Claude review: " Claude Code Review Bot
2026-03-23 16:45 ` [PATCH v2 3/4] drm: rcar-du: Use __free() to simplify device_node handling Laurent Pinchart
2026-03-24 21:42 ` Claude review: " Claude Code Review Bot
2026-03-23 16:45 ` [PATCH v2 4/4] drm: rcar-du: Don't leak device_link to CMM Laurent Pinchart
2026-03-24 21:42 ` Claude Code Review Bot [this message]
2026-03-24 21:42 ` Claude review: drm: rcar-du: Improve device_link handling Claude Code Review Bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch4-20260323164526.2292491-5-laurent.pinchart+renesas@ideasonboard.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox