Claude review: cgroup/dmem: allow max to be set below current usage

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

Patch Review

**Verdict: Good**

The core fix. Replaces:
```c
page_counter_set_max(&pool->cnt, val);
```
with:
```c
xchg(&pool->cnt.max, val);
```

This is correct. Looking at `page_counter_set_max()` in `mm/page_counter.c:197`, it uses an `xchg` internally but wraps it in a loop that returns `-EBUSY` when usage exceeds the new max. The return value was being silently discarded by `set_resource_max()` (which returns `void`), causing the write to appear successful while the limit remained unchanged.

The direct `xchg` unconditionally sets the max, which:
1. Has the correct memory ordering semantics (full barrier, matching what `page_counter_try_charge` expects)
2. Prevents new allocations from exceeding the new limit
3. Matches the intended memcg-like behavior where setting max below usage is allowed

One consideration: `page_counter_set_max` was designed with the read-swap-read pattern to ensure coherency with `page_counter_try_charge`. By doing a bare `xchg` without the subsequent usage check, there's a theoretical window where a concurrent charge could slip through if it read the old (higher) max just before the `xchg`. However, this is the same race that exists in memcg's `memory.max` write path (which also just does `WRITE_ONCE` on the max), and is acceptable — the charge will be caught on the next attempt. This is fine.

---
Generated by Claude Code Patch Reviewer