Claude review: drm/xe: use krealloc_array to prevent integer overflow

Claude review: drm/xe: use krealloc_array to prevent integer overflow

[Claude Code Review Bot]

Overall Series Review

Subject: drm/xe: use krealloc_array to prevent integer overflow
Author: "Baoli.Zhang" <baoli.zhang@linux.intel.com>
Patches: 1
Reviewed: 2026-03-25T07:53:35.984719

---

This is a single-patch series that mechanically replaces `krealloc()` with `krealloc_array()` in two xe driver files. The change is correct in principle — `krealloc_array()` adds an internal overflow check on the multiplication of `count * element_size` — but the practical overflow risk in both call sites is negligible:

1. In `xe_configfs.c`, `count` is a `ssize_t` derived from parsing a user-provided configfs page (bounded by page size), and `sizeof(u32)` is 4. Overflow of `count * 4` is not realistic.
2. In `xe_vm_madvise.c`, `max_vmas` is an `int` starting at 8 and doubling. It would need to reach ~2^30 entries (billions of VMAs) before `max_vmas * sizeof(pointer)` overflows, which is impossible in practice.

That said, using `krealloc_array()` is the accepted kernel coding convention for array allocations and tools like Coccinelle flag these patterns, so the change is reasonable as a hardening/cleanup measure.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/xe: use krealloc_array to prevent integer overflow

[Claude Code Review Bot]

Patch Review

**Correctness:** The transformation is mechanically correct in both hunks. The arguments are split properly: the original `count * sizeof(u32)` becomes `count, sizeof(u32)`, and `max_vmas * sizeof(*madvise_range->vmas)` becomes `max_vmas, sizeof(*madvise_range->vmas)`.

**Commit message nit:** The subject says "prevent integer overflow" which slightly overstates the risk. Both call sites have values bounded well below overflow thresholds. A more accurate subject would be something like "use krealloc_array to guard against potential integer overflow" or "use krealloc_array for overflow-safe allocation". This is a minor style point.

**Signed-off-by ordering:** The patch has:
```
Signed-off-by: Baoli.Zhang <baoli.zhang@linux.intel.com>
Signed-off-by: Junxiao.Chang <junxiao.chang@intel.com>
```
The `From:` header shows Baoli.Zhang as the author, so Junxiao.Chang's Signed-off-by appearing second (after the author) implies Junxiao.Chang is forwarding the patch. If Junxiao.Chang is a co-developer rather than a submitter in the chain, a `Co-developed-by:` + `Signed-off-by:` pair would be more appropriate.

**xe_vm_madvise.c alignment:** The alignment of the continuation arguments is slightly off from the opening parenthesis convention:
```c
__vmas = krealloc_array(madvise_range->vmas,
                  max_vmas,
                  sizeof(*madvise_range->vmas),
                  GFP_KERNEL);
```
The arguments after the first line are indented with tabs+spaces to roughly column-align, but they don't align with the first argument after the opening `(`. This is a minor style issue — matching the existing indentation style of the surrounding code is fine.

**Overall:** A straightforward and correct cleanup patch. No functional concerns. Recommend accepting with optional minor commit message adjustment.

---
Generated by Claude Code Patch Reviewer

[PATCH v2] drm/xe: use krealloc_array to prevent integer overflow

[Baoli.Zhang]

Replace the use of krealloc() with krealloc_array() in xe driver to
mitigate the risk of integer overflow during memory allocation size
calculation.

Signed-off-by: Baoli.Zhang <baoli.zhang@linux.intel.com>
Signed-off-by: Junxiao.Chang <junxiao.chang@intel.com>
---
Changes in v2:
- Adjust continuation-line indentation in xe_vm_madvise.c (no functional change).

v1: https://patchwork.freedesktop.org/patch/713422/?series=163696&rev=1

 drivers/gpu/drm/xe/xe_configfs.c   | 2 +-
 drivers/gpu/drm/xe/xe_vm_madvise.c | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_configfs.c b/drivers/gpu/drm/xe/xe_configfs.c
index 7fd07d1280bb1..4cf903c904ba0 100644
--- a/drivers/gpu/drm/xe/xe_configfs.c
+++ b/drivers/gpu/drm/xe/xe_configfs.c
@@ -766,7 +766,7 @@ static ssize_t wa_bb_store(struct wa_bb wa_bb[static XE_ENGINE_CLASS_MAX],
 	 * 2. Allocate a u32 array and set the pointers to the right positions
 	 * according to the length of each class' wa_bb
 	 */
-	tmp = krealloc(wa_bb[0].cs, count * sizeof(u32), GFP_KERNEL);
+	tmp = krealloc_array(wa_bb[0].cs, count, sizeof(u32), GFP_KERNEL);
 	if (!tmp)
 		return -ENOMEM;
 
diff --git a/drivers/gpu/drm/xe/xe_vm_madvise.c b/drivers/gpu/drm/xe/xe_vm_madvise.c
index bc39a9a9790c3..c90fea2b3d808 100644
--- a/drivers/gpu/drm/xe/xe_vm_madvise.c
+++ b/drivers/gpu/drm/xe/xe_vm_madvise.c
@@ -63,9 +63,10 @@ static int get_vmas(struct xe_vm *vm, struct xe_vmas_in_madvise_range *madvise_r
 
 		if (madvise_range->num_vmas == max_vmas) {
 			max_vmas <<= 1;
-			__vmas = krealloc(madvise_range->vmas,
-					  max_vmas * sizeof(*madvise_range->vmas),
-					  GFP_KERNEL);
+			__vmas = krealloc_array(madvise_range->vmas,
+						max_vmas,
+						sizeof(*madvise_range->vmas),
+						GFP_KERNEL);
 			if (!__vmas) {
 				kfree(madvise_range->vmas);
 				return -ENOMEM;
-- 
2.43.0

Claude review: drm/xe: use krealloc_array to prevent integer overflow

[Claude Code Review Bot]

Overall Series Review

Subject: drm/xe: use krealloc_array to prevent integer overflow
Author: "Baoli.Zhang" <baoli.zhang@linux.intel.com>
Patches: 1
Reviewed: 2026-04-12T11:54:39.270190

---

This is a single patch (v2) that mechanically replaces `krealloc()` with `krealloc_array()` in two xe driver files to leverage the built-in overflow checking in `krealloc_array()`. The change is correct, low-risk, and follows established kernel conventions. The kernel provides `krealloc_array()` specifically for this pattern — separating count from element size so the allocator can check for multiplication overflow internally.

The practical overflow risk here is low (especially in `xe_vm_madvise.c` where `max_vmas` starts at 8 and doubles, so it would OOM long before overflowing), but using the safe API is the right thing to do as a defense-in-depth measure. In `xe_configfs.c`, `count` is a `ssize_t` derived from user-supplied configfs input, so the overflow protection is slightly more meaningful there.

**Verdict: Looks good.** Minor nits below but nothing blocking.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/xe: use krealloc_array to prevent integer overflow

[Claude Code Review Bot]

Patch Review

**xe_configfs.c change:**

```c
-	tmp = krealloc(wa_bb[0].cs, count * sizeof(u32), GFP_KERNEL);
+	tmp = krealloc_array(wa_bb[0].cs, count, sizeof(u32), GFP_KERNEL);
```

Correct transformation. `count` is `ssize_t` (line 755), so the original `count * sizeof(u32)` is a `size_t` multiplication that could theoretically wrap. `krealloc_array()` handles this safely. One observation: `count` can be 0 here (there's an explicit `if (!count)` check at line 776 after the allocation), and `krealloc_array` with count=0 will behave as `ZERO_SIZE_PTR` or free — the existing code handles this path correctly since `!tmp` is checked and the `!count` case returns early anyway.

**xe_vm_madvise.c change:**

```c
-		__vmas = krealloc(madvise_range->vmas,
-				  max_vmas * sizeof(*madvise_range->vmas),
-				  GFP_KERNEL);
+		__vmas = krealloc_array(madvise_range->vmas,
+					max_vmas,
+					sizeof(*madvise_range->vmas),
+					GFP_KERNEL);
```

Correct transformation. `max_vmas` is `int` starting at 8 and doubling (`max_vmas <<= 1`). The overflow risk is theoretical (would need ~2^31 VMAs), but using the safe API is the right pattern. The continuation-line alignment matches the opening parenthesis, which is the expected kernel style.

**Nit (non-blocking):** The Signed-off-by chain has `Junxiao.Chang` as a second signoff but there's no `Co-developed-by` tag, nor is there a `Reviewed-by` or `Suggested-by`. If Junxiao co-developed this, kernel convention requires a `Co-developed-by` tag immediately before their `Signed-off-by`. If they only reviewed it, it should be `Reviewed-by` instead.

**Overall: Reviewed-by worthy.** Straightforward, correct, mechanical improvement.

---
Generated by Claude Code Patch Reviewer