public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
* [PATCH] drm/xe: Don't emit UTS_RELEASE as part of device coredump
@ 2026-04-27 16:09 Uwe Kleine-König (The Capable Hub)
  2026-04-27 20:32 ` Uwe Kleine-König (The Capable Hub)
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Uwe Kleine-König (The Capable Hub) @ 2026-04-27 16:09 UTC (permalink / raw)
  To: Matthew Brost, Thomas Hellström, Rodrigo Vivi
  Cc: David Airlie, Simona Vetter, intel-xe, dri-devel, linux-kernel

UTS_RELEASE changes quite easily (e.g. uncommitted changes in the source
tree or new commits). So when checking if a patch introduces changes to the
resulting binary each usage of UTS_RELEASE is a source of annoyance as
it introduces changes not caused by the change under test.

It's little helpful to emit the kernel version in the device coredump, so
drop the kernel version line from it.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,

I'm not really sure if my assertion above that the kernel version isn't
helpful is actually true.

If yes, there are a few more very similar changes to make:

	$ git grep -E 'drm_p.*UTS_RELEASE' v7.1-rc1 drivers/gpu/
	v7.1-rc1:drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c:      drm_printf(&p, "kernel: " UTS_RELEASE "\n");
	v7.1-rc1:drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c:     drm_printf(p, "kernel: " UTS_RELEASE "\n");
	v7.1-rc1:drivers/gpu/drm/msm/msm_gpu.c: drm_printf(&p, "kernel: " UTS_RELEASE "\n");
	v7.1-rc1:drivers/gpu/drm/xe/xe_devcoredump.c:   drm_puts(&p, "kernel: " UTS_RELEASE "\n");

Best regards
Uwe

 drivers/gpu/drm/xe/xe_devcoredump.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
index 558a1a9841a0..260e3f19286b 100644
--- a/drivers/gpu/drm/xe/xe_devcoredump.c
+++ b/drivers/gpu/drm/xe/xe_devcoredump.c
@@ -101,7 +101,6 @@ static ssize_t __xe_devcoredump_read(char *buffer, ssize_t count,
 
 	drm_puts(&p, "**** Xe Device Coredump ****\n");
 	drm_printf(&p, "Reason: %s\n", ss->reason);
-	drm_puts(&p, "kernel: " UTS_RELEASE "\n");
 	drm_puts(&p, "module: " KBUILD_MODNAME "\n");
 
 	ts = ktime_to_timespec64(ss->snapshot_time);

base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] drm/xe: Don't emit UTS_RELEASE as part of device coredump
  2026-04-27 16:09 [PATCH] drm/xe: Don't emit UTS_RELEASE as part of device coredump Uwe Kleine-König (The Capable Hub)
@ 2026-04-27 20:32 ` Uwe Kleine-König (The Capable Hub)
  2026-04-27 22:05 ` Rodrigo Vivi
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Uwe Kleine-König (The Capable Hub) @ 2026-04-27 20:32 UTC (permalink / raw)
  To: Matthew Brost, Thomas Hellström, Rodrigo Vivi
  Cc: David Airlie, Simona Vetter, intel-xe, dri-devel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2488 bytes --]

On Mon, Apr 27, 2026 at 06:09:03PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> UTS_RELEASE changes quite easily (e.g. uncommitted changes in the source
> tree or new commits). So when checking if a patch introduces changes to the
> resulting binary each usage of UTS_RELEASE is a source of annoyance as
> it introduces changes not caused by the change under test.
> 
> It's little helpful to emit the kernel version in the device coredump, so
> drop the kernel version line from it.
> 
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
> 
> I'm not really sure if my assertion above that the kernel version isn't
> helpful is actually true.
> 
> If yes, there are a few more very similar changes to make:
> 
> 	$ git grep -E 'drm_p.*UTS_RELEASE' v7.1-rc1 drivers/gpu/
> 	v7.1-rc1:drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c:      drm_printf(&p, "kernel: " UTS_RELEASE "\n");
> 	v7.1-rc1:drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c:     drm_printf(p, "kernel: " UTS_RELEASE "\n");
> 	v7.1-rc1:drivers/gpu/drm/msm/msm_gpu.c: drm_printf(&p, "kernel: " UTS_RELEASE "\n");
> 	v7.1-rc1:drivers/gpu/drm/xe/xe_devcoredump.c:   drm_puts(&p, "kernel: " UTS_RELEASE "\n");
> 
> Best regards
> Uwe
> 
>  drivers/gpu/drm/xe/xe_devcoredump.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
> index 558a1a9841a0..260e3f19286b 100644
> --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
> @@ -101,7 +101,6 @@ static ssize_t __xe_devcoredump_read(char *buffer, ssize_t count,
>  
>  	drm_puts(&p, "**** Xe Device Coredump ****\n");
>  	drm_printf(&p, "Reason: %s\n", ss->reason);
> -	drm_puts(&p, "kernel: " UTS_RELEASE "\n");
>  	drm_puts(&p, "module: " KBUILD_MODNAME "\n");
>  
>  	ts = ktime_to_timespec64(ss->snapshot_time);
> 
FTR: If the patch is acceptable, the following should be squashed into
it:

diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
index 260e3f19286b..4ed1e4afa4c6 100644
--- a/drivers/gpu/drm/xe/xe_devcoredump.c
+++ b/drivers/gpu/drm/xe/xe_devcoredump.c
@@ -8,7 +8,6 @@
 
 #include <linux/ascii85.h>
 #include <linux/devcoredump.h>
-#include <generated/utsrelease.h>
 
 #include <drm/drm_managed.h>
 

I will wait with a new revision in the hope to get some feedback first.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] drm/xe: Don't emit UTS_RELEASE as part of device coredump
  2026-04-27 16:09 [PATCH] drm/xe: Don't emit UTS_RELEASE as part of device coredump Uwe Kleine-König (The Capable Hub)
  2026-04-27 20:32 ` Uwe Kleine-König (The Capable Hub)
@ 2026-04-27 22:05 ` Rodrigo Vivi
  2026-04-28  4:25 ` Claude review: " Claude Code Review Bot
  2026-04-28  4:25 ` Claude Code Review Bot
  3 siblings, 0 replies; 5+ messages in thread
From: Rodrigo Vivi @ 2026-04-27 22:05 UTC (permalink / raw)
  To: Uwe Kleine-König (The Capable Hub)
  Cc: Matthew Brost, Thomas Hellström, David Airlie, Simona Vetter,
	intel-xe, dri-devel, linux-kernel

On Mon, Apr 27, 2026 at 06:09:03PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> UTS_RELEASE changes quite easily (e.g. uncommitted changes in the source

we know, this is exactly why we use it ;)
We want to be able to differentiate if it is a distro build versus custom build.

> tree or new commits). So when checking if a patch introduces changes to the
> resulting binary each usage of UTS_RELEASE is a source of annoyance as
> it introduces changes not caused by the change under test.
> 
> It's little helpful to emit the kernel version in the device coredump, so
> drop the kernel version line from it.

That's a driver decision, no?!
We think it is useful and this change breaks the tools that are parsing it.
So, please drop this patch.

Thanks,
Rodrigo.

> 
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
> 
> I'm not really sure if my assertion above that the kernel version isn't
> helpful is actually true.
> 
> If yes, there are a few more very similar changes to make:
> 
> 	$ git grep -E 'drm_p.*UTS_RELEASE' v7.1-rc1 drivers/gpu/
> 	v7.1-rc1:drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c:      drm_printf(&p, "kernel: " UTS_RELEASE "\n");
> 	v7.1-rc1:drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c:     drm_printf(p, "kernel: " UTS_RELEASE "\n");
> 	v7.1-rc1:drivers/gpu/drm/msm/msm_gpu.c: drm_printf(&p, "kernel: " UTS_RELEASE "\n");
> 	v7.1-rc1:drivers/gpu/drm/xe/xe_devcoredump.c:   drm_puts(&p, "kernel: " UTS_RELEASE "\n");
> 
> Best regards
> Uwe
> 
>  drivers/gpu/drm/xe/xe_devcoredump.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
> index 558a1a9841a0..260e3f19286b 100644
> --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
> @@ -101,7 +101,6 @@ static ssize_t __xe_devcoredump_read(char *buffer, ssize_t count,
>  
>  	drm_puts(&p, "**** Xe Device Coredump ****\n");
>  	drm_printf(&p, "Reason: %s\n", ss->reason);
> -	drm_puts(&p, "kernel: " UTS_RELEASE "\n");
>  	drm_puts(&p, "module: " KBUILD_MODNAME "\n");
>  
>  	ts = ktime_to_timespec64(ss->snapshot_time);
> 
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> -- 
> 2.47.3
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Claude review: drm/xe: Don't emit UTS_RELEASE as part of device coredump
  2026-04-27 16:09 [PATCH] drm/xe: Don't emit UTS_RELEASE as part of device coredump Uwe Kleine-König (The Capable Hub)
                   ` (2 preceding siblings ...)
  2026-04-28  4:25 ` Claude review: " Claude Code Review Bot
@ 2026-04-28  4:25 ` Claude Code Review Bot
  3 siblings, 0 replies; 5+ messages in thread
From: Claude Code Review Bot @ 2026-04-28  4:25 UTC (permalink / raw)
  To: dri-devel-reviews

Overall Series Review

Subject: drm/xe: Don't emit UTS_RELEASE as part of device coredump
Author: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?=
 <u.kleine-koenig@baylibre.com>
Patches: 3
Reviewed: 2026-04-28T14:25:21.271181

---

This is a single-patch series that removes the `UTS_RELEASE` (kernel version string) from the Xe device coredump output. The stated motivation is build reproducibility: `UTS_RELEASE` changes with any uncommitted change or new commit, causing binary differences that are noise when evaluating whether a source patch changes the compiled output.

The patch is technically trivial and correct — it cleanly removes one line. However, the author themselves express doubt in the cover letter: *"I'm not really sure if my assertion above that the kernel version isn't helpful is actually true."*

**This is the key concern.** The kernel version in a device coredump is actually quite useful for debugging. When a user files a GPU hang bug report with a coredump attached, knowing the exact kernel version is important for reproducing the issue and correlating with known bugs. Other GPU drivers (amdgpu, msm) emit the same `kernel: UTS_RELEASE` line in their coredumps for this reason. Removing it from xe while leaving it in amdgpu and msm creates an inconsistency across DRM drivers.

The build reproducibility concern is legitimate, but it's a development-time convenience issue, not a correctness issue. A developer tracking binary changes can filter or exclude `xe_devcoredump.o` from their comparison. The debugging value of having the kernel version in production coredumps likely outweighs the minor build-comparison annoyance.

**Recommendation:** This patch should probably be **NAK'd** unless there's a stronger justification. If the reproducibility concern is important enough, a better approach might be to emit the version at runtime (e.g., using `utsname()->release`) rather than at compile time, which would remove the build-reproducibility issue while preserving the debugging information. Alternatively, if the broader community agrees that `UTS_RELEASE` should be removed from coredumps, it should be done consistently across all DRM drivers, not just xe.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Claude review: drm/xe: Don't emit UTS_RELEASE as part of device coredump
  2026-04-27 16:09 [PATCH] drm/xe: Don't emit UTS_RELEASE as part of device coredump Uwe Kleine-König (The Capable Hub)
  2026-04-27 20:32 ` Uwe Kleine-König (The Capable Hub)
  2026-04-27 22:05 ` Rodrigo Vivi
@ 2026-04-28  4:25 ` Claude Code Review Bot
  2026-04-28  4:25 ` Claude Code Review Bot
  3 siblings, 0 replies; 5+ messages in thread
From: Claude Code Review Bot @ 2026-04-28  4:25 UTC (permalink / raw)
  To: dri-devel-reviews

Patch Review

**Correctness:** The patch is mechanically correct. It removes one `drm_puts` call and the surrounding code compiles fine without it.

**Concern — Loss of diagnostic information:**

```c
-	drm_puts(&p, "kernel: " UTS_RELEASE "\n");
```

This line provides the kernel version in coredumps. When users submit bug reports with coredump data attached, the kernel version is one of the first things developers check. Removing it means developers will need to ask users for this information separately or rely on other metadata (e.g., dmesg, uname output) that may not always be included in the report.

**Concern — Inconsistency with other drivers:**

The author's own grep shows that amdgpu, msm, and xe all emit `UTS_RELEASE` in their coredumps. Removing it from xe alone creates an inconsistency. If this change is desirable, it should be a series covering all DRM drivers that use this pattern.

**Concern — Weak justification:**

The commit message says *"It's little helpful to emit the kernel version in the device coredump"* but doesn't provide evidence for this claim. The author even hedges in the cover letter. Build reproducibility is a valid concern but is a niche developer workflow issue, not a reason to remove diagnostic data from production coredumps.

**Alternative approach:** If the goal is to avoid compile-time `UTS_RELEASE` dependencies, the line could be changed to use the runtime equivalent:

```c
drm_printf(&p, "kernel: %s\n", utsname()->release);
```

This would emit the same information at dump time without causing `xe_devcoredump.o` to be rebuilt when `UTS_RELEASE` changes. This addresses the build reproducibility concern while preserving the diagnostic value.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-04-28  4:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-27 16:09 [PATCH] drm/xe: Don't emit UTS_RELEASE as part of device coredump Uwe Kleine-König (The Capable Hub)
2026-04-27 20:32 ` Uwe Kleine-König (The Capable Hub)
2026-04-27 22:05 ` Rodrigo Vivi
2026-04-28  4:25 ` Claude review: " Claude Code Review Bot
2026-04-28  4:25 ` Claude Code Review Bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox