Claude review: cgroup,cgroup/dmem: Add (dmem_)cgroup_common_ancestor helper

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

Patch Review

Adds `cgroup_common_ancestor()` to `include/linux/cgroup.h` and `dmem_cgroup_get_common_ancestor()` to dmem.

The `cgroup_common_ancestor()` implementation is clean — walks from `min(a->level, b->level)` downward checking `ancestors[]`. This is correct since two cgroups in the same hierarchy share ancestors at every level up to and including their LCA.

**Doc typo in `dmem_cgroup_get_common_ancestor()`**:
```
 * @b: First pool to find the common ancestor of.
```
Should say `@b: Second pool...`.

**Potential concern**: `dmem_cgroup_get_common_ancestor()` calls `cgroup_e_css()` and then `get_cg_pool_unlocked()`. The `cgroup_e_css()` call is done without holding `rcu_read_lock()`. Looking at the kernel, `cgroup_e_css()` dereferences `cgroup->subsys[]` which is RCU-protected. This should be called under `rcu_read_lock()`, or the caller should hold a reference that prevents the css from going away. The css obtained from `cgroup_e_css()` is passed to `css_to_dmemcs()` and then to `get_cg_pool_unlocked()` — if the css could be freed between these calls, this is a use-after-free. This warrants investigation: does the fact that `a` and `b` are alive (and hold references to their respective css) guarantee that the common ancestor's css is also alive? In cgroup v2 with a unified hierarchy this should be the case since parents can't be destroyed while children exist, but this should be documented or protected with `rcu_read_lock()` + `css_get()`.

---
Generated by Claude Code Patch Reviewer