Claude review: drm/xe/drm_ras: Add per node cleanup action

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

Patch Review

**Verdict: Correct, with one observation.**

This is the most substantial change. It replaces the monolithic `xe_drm_ras_unregister_nodes()` cleanup (registered once for all nodes) with per-node `drmm_add_action_or_reset()` calls, guaranteeing that each successfully-initialized node is cleaned up individually during unwind.

The error paths in `register_nodes()` are carefully structured:

```c
ret = drmm_add_action_or_reset(&xe->drm, cleanup_node, node);
if (ret)
    goto null_info;
```

Jumping to `null_info` (not `free_param`) on `drmm_add_action_or_reset` failure is critical. Since the `_or_reset` variant calls `cleanup_node()` itself on failure (which frees `device_name` and unregisters the node), jumping to `free_param` would double-free `device_name`. The v3 changelog confirms this was caught by a reviewer — good catch.

**Observation:** After patch 3, `cleanup_node_param()` no longer NULLs out `ras->info[severity]`. During normal device teardown, the drmm actions run `cleanup_node()` → `cleanup_node_param()`, which frees `device_name` but leaves `ras->info[severity]` as a dangling pointer (the counter memory is freed separately by its own drmm tracking). This is safe because the xe_device is being torn down, but it's a departure from the defensive NULL-after-free pattern. Worth noting but not blocking — the init-time error path in `register_nodes()` does NULL it out via `null_info`, which is the path where it matters.

**Teardown ordering is correct:** drmm releases in reverse registration order, so per-node `cleanup_node` actions run before the node array itself is freed (`drmm_kcalloc` in `xe_drm_ras_init`), ensuring the nodes are still valid when `drm_ras_node_unregister` and `cleanup_node_param` access them.

---

---
Generated by Claude Code Patch Reviewer