Claude review: drm/fdinfo: Add "evicted" memory accounting

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

Patch Review

**Summary:** Adds `DRM_GEM_OBJECT_EVICTED` (BIT(3)) to `enum drm_gem_object_status`, adds `u64 evicted` to `struct drm_memory_stats`, and wires both into the fdinfo printing and accumulation paths.

**Review:**

The changes correctly follow the established pattern used by `RESIDENT`, `PURGEABLE`, and `ACTIVE`. The new enum value is properly documented with a kdoc comment.

**Issue 1 (minor): The "evicted" accumulation in `drm_show_memory_stats` uses `add_size` unconditionally.**

```c
		if (s & DRM_GEM_OBJECT_EVICTED)
			status.evicted += add_size;
```

This uses `add_size`, which is the RSS size (from `obj->funcs->rss()` if available, otherwise `obj->size`). For an evicted object, `rss()` would typically return 0 since the pages are gone. In the panthor driver (patch 2), evicted objects won't have `DRM_GEM_OBJECT_RESIDENT` set, so they won't have backing pages — meaning `rss()` would return 0 (or not be meaningful).

For evicted objects, the interesting number is the *total* size of the object (how much was evicted to swap), not the RSS. Consider using `obj->size` instead of `add_size`, or document why `add_size` is correct here.

**Issue 2 (minor/doc): The `@DRM_GEM_OBJECT_EVICTED` doc says "object is evicted to swap".**

```c
 * @DRM_GEM_OBJECT_EVICTED: object is evicted to swap
```

The commit message mentions this is about pages being swapped out, but "evicted" in the GPU driver world often means "evicted from VRAM to system memory" (e.g., in TTM-based drivers). The doc comment and the enum value name could potentially be confused with VRAM eviction. Consider whether the description should be more specific, e.g. "object's backing pages have been reclaimed by the shrinker." This is a naming/documentation concern rather than a correctness issue.

**Issue 3 (question): Interaction with existing `RESIDENT`/`PURGEABLE` filtering logic.**

In `drm_show_memory_stats`, when an object is not `RESIDENT`, the code clears `PURGEABLE`:
```c
		if (s & DRM_GEM_OBJECT_RESIDENT) {
			status.resident += add_size;
		} else {
			s &= ~DRM_GEM_OBJECT_PURGEABLE;
		}
```

The new `EVICTED` status is accumulated *after* this block (based on the patch context), which is correct since evicted objects should be non-resident by definition. But there's no explicit mutual exclusivity check — a driver could theoretically return both `RESIDENT` and `EVICTED`, which would be nonsensical. This is not a bug (drivers shouldn't do this), but a comment noting that `EVICTED` is expected to be mutually exclusive with `RESIDENT` would be helpful in the enum documentation.

**Issue 4 (nit): Missing documentation update.**

The `drm_gem_object_status` enum doc block has a long comment about the interaction between `PURGEABLE`, `RESIDENT`, and `ACTIVE`. It would be good to add a similar note about `EVICTED` — specifically that it should only be set for non-resident objects whose pages were previously allocated and then reclaimed, and that it is mutually exclusive with `RESIDENT`.

**Positive:** The `drm_memory_stats_is_zero` check is correctly updated, and the printing order (after purgeable) is reasonable.

---

---
Generated by Claude Code Patch Reviewer