Claude review: accel/amdxdna: Remove drv_cmd tracing from job free callback

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Correctness: Good.** The use-after-free is real. The callers in `aie2_hwctx_cfg_debug_bo()` and `aie2_hwctx_sync_debug_bo()` pass a pointer to a stack-local `struct amdxdna_drv_cmd cmd`:

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

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

```c
job->drv_cmd = 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 `job->drv_cmd` a dangling pointer. The fix correctly removes the access.

**Minor observation:** The added comment says `/* job->drv_cmd could be freed, so use DEFAULT_IO */`, but strictly speaking `drv_cmd` points to a stack-local — 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 switch 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 — the caller is blocked in `aie2_cmd_wait()` at that point, so the stack-local `cmd` is still valid. Those accesses are fine.

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

---
Generated by Claude Code Patch Reviewer