Claude review: selftests/dmabuf-heaps: Add dma-buf memcg accounting tests

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

Patch Review

Adds tests for the charge_pid_fd feature in both the dmabuf-heaps and cgroup test suites, plus a vmtest.sh script.

**Issue 1 - Feature detection:**
```c
+static bool pidfd_alloc_supported(int heap_fd)
+{
+	int devnull_fd, dmabuf_fd = -1, ret;
+	devnull_fd = open("/dev/null", O_RDONLY);
+	...
+	ret = dmabuf_heap_alloc_pidfd(heap_fd, ONE_MEG, 0, devnull_fd, &dmabuf_fd);
```
This probes by passing `/dev/null` as a pidfd and checking for failure. The logic `return ret < 0` assumes that if the ioctl fails with a non-pidfd, the kernel supports the field. But on an old kernel that ignores the new fields (because of the zero-fill ioctl handling), the ioctl would *succeed* (allocating without any pidfd charging), and `ret` would be 0. Then `return ret < 0` returns `false`, meaning "not supported" — which is wrong. The detection logic should check whether the failure mode indicates the field was recognized, e.g., by checking for `-EBADF` (bad fd) specifically, rather than any failure. On an old kernel the ioctl would succeed (ignoring the extra bytes), so the probe returns "not supported," which happens to be correct since the old kernel wouldn't act on the field. Actually on reflection this works by accident — the old kernel zero-fills the extra fields and ignores them, the ioctl succeeds, and `ret < 0` is false, correctly indicating the feature isn't supported. But the function also allocates a 1MB dma-buf on old kernels as a side effect, which leaks until `dmabuf_fd` is closed. Actually, looking again: `if (dmabuf_fd >= 0) close(dmabuf_fd)` handles that case. OK, the detection logic is correct but fragile — it depends on the specific failure mode. A comment explaining the detection strategy would help.

**Issue 2 - test_memcontrol filtering:** The patch adds command-line filtering to test_memcontrol's main():
```c
+	if (argc > 1)
+		filter = argv[1];
```
This is a useful utility change but is unrelated to dma-buf accounting. It should be a separate preparatory patch.

**Issue 3 - Missing error path tests:** The selftests cover the happy path (self pidfd, child pidfd, cross-cgroup accounting) but don't test:
- Invalid pidfd (non-pidfd fd)
- Pidfd pointing to an exited process
- Allocation exceeding the target cgroup's memory limit
- Simultaneous charging from multiple allocators

**Issue 4 - `cg_read_key_long_poll` usage:** The test polls up to 15 times with 200ms delays:
```c
+	if (dmabuf_stat != ONE_MEG)
+		dmabuf_stat = cg_read_key_long_poll(child_cg, "memory.stat",
+						    "dmabuf ", ONE_MEG,
+						    15, 200000);
```
The stat update should be synchronous (it happens in the charge path), so the need for polling suggests either the stat is lazy-flushed or there's a timing issue. If the charge is synchronous, a single read with a brief delay should suffice.

---
Generated by Claude Code Patch Reviewer