From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/dumb-buffer: Drop buffer-size limits for now
Date: Thu, 04 Jun 2026 12:51:36 +1000 [thread overview]
Message-ID: <review-patch1-20260602112842.252279-1-tzimmermann@suse.de> (raw)
In-Reply-To: <20260602112842.252279-1-tzimmermann@suse.de>
Patch Review
**Correctness: Good**
The removed check was:
```c
- if (args->width >= 8192 || args->height >= 8192 || args->bpp > 32)
- return -EINVAL;
```
This was problematic for two reasons:
1. **The `bpp > 32` check contradicts `drm_mode_size_dumb()`**, which explicitly supports `case 64:` (for `XRGB16161616F` and friends) at line 176 of the current tree. Any driver using `drm_mode_size_dumb()` for 64bpp formats would have the request rejected before reaching the helper.
2. **The `width >= 8192` check is too restrictive** — 8K displays are 7680x4320, which barely passes, but any buffer slightly wider than the display (e.g., with stride alignment padding) would be rejected. The `>=` rather than `>` means even exactly 8192 fails.
**Remaining overflow protection is adequate.** The existing checks that remain:
```c
if (args->bpp > U32_MAX - 8) // prevents DIV_ROUND_UP overflow
return -EINVAL;
cpp = DIV_ROUND_UP(args->bpp, 8);
if (cpp > U32_MAX / args->width) // prevents pitch overflow
return -EINVAL;
stride = cpp * args->width;
if (args->height > U32_MAX / stride) // prevents size overflow
return -EINVAL;
size = args->height * stride;
if (PAGE_ALIGN(size) == 0) // prevents wrap-around
return -EINVAL;
```
These four checks form a complete chain that prevents every 32-bit arithmetic overflow in the computation path. The hard size limits were belt-and-suspenders but broke real users.
**Downstream driver concern acknowledged.** The commit message correctly notes that drivers not yet using `drm_mode_size_dumb()` should be updated. Those drivers do their own alignment math in their `dumb_create` callbacks and may still be individually vulnerable to overflow, but that's a pre-existing issue not introduced by this patch.
**Minor nit — tag ordering.** The `Fixes:` tag appears after `Signed-off-by:`, which is unconventional. Kernel convention typically places `Fixes:` before `Signed-off-by:` in the trailer block:
```
Fixes: 5ab62dd3687b ("drm: prevent integer overflows in dumb buffer creation helpers")
Reported-by: Jani Nikula <jani.nikula@linux.intel.com>
Closes: https://lore.kernel.org/dri-devel/...
Cc: ...
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
```
This is cosmetic and doesn't affect tooling, but worth fixing if a v2 is sent for other reasons.
---
Generated by Claude Code Patch Reviewer
prev parent reply other threads:[~2026-06-04 2:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 11:24 [PATCH] drm/dumb-buffer: Drop buffer-size limits for now Thomas Zimmermann
2026-06-03 8:53 ` Saarinen, Jani
2026-06-03 10:30 ` Jani Nikula
2026-06-04 2:51 ` Claude review: " Claude Code Review Bot
2026-06-04 2:51 ` Claude Code Review Bot [this message]
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-patch1-20260602112842.252279-1-tzimmermann@suse.de \
--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