From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: accel/amdxdna: Remove drv_cmd tracing from job free callback
Date: Thu, 04 Jun 2026 16:19:39 +1000
Message-ID: <review-patch1-20260529152837.1973405-1-lizhi.hou@amd.com>
In-Reply-To: <20260529152837.1973405-1-lizhi.hou@amd.com>
References: <20260529152837.1973405-1-lizhi.hou@amd.com> <20260529152837.1973405-1-lizhi.hou@amd.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

**Correctness: Good.** The use-after-free is real. The callers in `aie2_hwc=
tx_cfg_debug_bo()` and `aie2_hwctx_sync_debug_bo()` pass a pointer to a sta=
ck-local `struct amdxdna_drv_cmd cmd`:

```c
struct amdxdna_drv_cmd cmd =3D { 0 };
...
ret =3D amdxdna_cmd_submit(client, &cmd, ...);
```

And in `amdxdna_cmd_submit()` this is stored as a bare pointer:

```c
job->drv_cmd =3D drv_cmd;
```

Since `aie2_sched_job_free` runs asynchronously via `drm_sched_backend_ops.=
free_job`, it can execute after the caller's stack frame is gone, making `j=
ob->drv_cmd` a dangling pointer. The fix correctly removes the access.

**Minor observation:** The added comment says `/* job->drv_cmd could be fre=
ed, so use DEFAULT_IO */`, but strictly speaking `drv_cmd` points to a stac=
k-local =E2=80=94 it isn't "freed" in the heap sense, the stack frame just =
goes out of scope. A more precise comment might say "could be invalid" or "=
may point to freed/stale memory." This is very minor and doesn't affect the=
 fix.

**Other `drv_cmd` accesses:** The other uses of `job->drv_cmd` in `aie2_ctx=
.c` (the "signaling fence" trace at line 212, "job run" at line 384, the sw=
itch at line 395, and "sent to device" at line 429) all happen within `aie2=
_sched_job_run()` or its signal callback path, which runs while the job is =
actively submitted =E2=80=94 the caller is blocked in `aie2_cmd_wait()` at =
that point, so the stack-local `cmd` is still valid. Those accesses are fin=
e.

**Reviewed-by criteria:** This is a clean, minimal fix for a real bug. No c=
oncerns.

---
Generated by Claude Code Patch Reviewer