From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/ttm: Split cgroup charge and resource allocation Date: Tue, 03 Mar 2026 13:29:38 +1000 Message-ID: In-Reply-To: <20260302-dmemcg-aggressive-protect-v5-4-ffd3a2602309@gmx.de> References: <20260302-dmemcg-aggressive-protect-v5-0-ffd3a2602309@gmx.de> <20260302-dmemcg-aggressive-protect-v5-4-ffd3a2602309@gmx.de> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Purpose:** Decouples cgroup charging from resource allocation so the char= ge persists across allocation retries. This prevents a TOCTOU race where pr= otection status is checked without the allocation being charged. **Design:** This is a key enabler for patch 5. The new `ttm_resource_try_ch= arge()` charges the cgroup first, then `ttm_resource_alloc()` takes the cha= rged pool directly. The charge ownership is transferred to the TTM resource= on success, with explicit cleanup on failure paths. The ownership transfer is well-documented: ```c /* * Ownership of charge_pool has been transferred to the TTM resource, * don't make the caller think we still hold a reference to it. */ alloc_state->charge_pool =3D NULL; ``` **Eviction callback charge attempt:** In `ttm_bo_evict_cb`, after successfu= l eviction: ```c if (!evict_walk->alloc_state->charge_pool) { lret =3D ttm_resource_try_charge(bo, evict_walk->place, &evict_walk->alloc_state->charge_pool, NULL); if (lret =3D=3D -EAGAIN) return -EBUSY; else if (lret) return lret; } ``` The `-EAGAIN` =E2=86=92 `-EBUSY` mapping here will propagate up through `tt= m_lru_walk_for_evict`. Since `lret` will be negative, the `!lret` checks in= the retry loops won't trigger, effectively stopping the eviction walk. Thi= s seems correct =E2=80=94 if the cgroup limit prevents charging even after = eviction, there's no point continuing. `NULL` is passed for `ret_limit_pool` in the eviction callback's charge att= empt, which is fine since the limit pool was already established during the= initial `ttm_bo_alloc_at_place` call. The uncharge paths in `ttm_bo_alloc_resource` look correct =E2=80=94 `dmem_= cgroup_uncharge()` is called before `dmem_cgroup_pool_state_put()` on each = failure path, and the `-EBUSY` continue path also uncharges. --- Generated by Claude Code Patch Reviewer