Claude review: drm/ras: Introduce the DRM RAS infrastructure over generic netlink

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

Patch Review

**Bug: Memory leak in `doit_reply_value()`**

```c
ret = get_node_error_counter(node_id, error_id,
                             &error_name, &value);
if (ret)
    return ret;
```

At `drm_ras.c` (in the diff around line 930-934), when `get_node_error_counter()` fails, `msg` has already been allocated via `genlmsg_new()` but is never freed. This should be:
```c
if (ret) {
    nlmsg_free(msg);
    return ret;
}
```

**Bug: Uninitialized `ret` in `drm_ras_nl_list_nodes_dumpit()`**

```c
int ret;
xa_for_each_start(&drm_ras_xa, id, node, ctx->restart) {
    ...
}
if (ret == -EMSGSIZE)
    ctx->restart = id;
return ret;
```

If the xarray is empty, the loop body never executes and `ret` is returned uninitialized. Should be `int ret = 0;`. Same issue exists in `drm_ras_nl_get_error_counter_dumpit()`.

**Concern: No locking on xarray access**

`drm_ras_xa` is accessed from netlink handlers (which can run concurrently) and from driver register/unregister paths. `xa_for_each_start` and `xa_load` are used without RCU or other synchronization. While xarray itself has some internal locking for modifications, the *node pointer* returned by `xa_load()` could become stale if a concurrent unregister frees it. Consider using `rcu_read_lock()` / `xa_for_each` under RCU, or document the expected serialization.

**Concern: `netnsok = true` in genl family**

```c
struct genl_family drm_ras_nl_family __ro_after_init = {
    ...
    .netnsok    = true,
```

This allows the family to be used from non-init network namespaces. Is this intentional for a hardware RAS interface? Typically hardware error reporting should be restricted to the init namespace. Setting `netnsok = false` would be safer.

**Minor: YAML `error-value` is `u32`**

```yaml
      -
        name: error-value
        type: u32
        doc: Current value of the requested error counter.
```

For counters that can accumulate rapidly (especially with `hweight32` adding multiple bits per interrupt), u32 can overflow. Consider whether u64 would be more appropriate for an error counter that may be queried infrequently. This is a uAPI decision that will be hard to change later.

**Minor: `EXPORT_SYMBOL` vs `EXPORT_SYMBOL_GPL`**

```c
EXPORT_SYMBOL(drm_ras_node_register);
EXPORT_SYMBOL(drm_ras_node_unregister);
```

DRM typically uses `EXPORT_SYMBOL_GPL`. These should probably match the convention.

---
Generated by Claude Code Patch Reviewer