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: Extract code for attempting allocation in a place Date: Tue, 03 Mar 2026 13:29:38 +1000 Message-ID: In-Reply-To: <20260302-dmemcg-aggressive-protect-v5-3-ffd3a2602309@gmx.de> References: <20260302-dmemcg-aggressive-protect-v5-0-ffd3a2602309@gmx.de> <20260302-dmemcg-aggressive-protect-v5-3-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:** Refactoring =E2=80=94 extracts allocation-attempt logic into `= ttm_bo_alloc_at_place()` and introduces `struct ttm_bo_alloc_state` to trac= k allocation state across attempts. **Bug =E2=80=94 compile error:** ```c if (ret =3D=3D -EBUSY) continue; else if (ret) return; ``` This `return;` in a function returning `int` is a compile error. It should = be `return ret;`. While patch 4 restructures this code and happens to fix i= t, **this patch will not compile standalone**, breaking bisectability. This= must be fixed =E2=80=94 each patch in a series should compile cleanly. The `ttm_bo_alloc_state` struct and return-code convention (-EBUSY =3D retr= y with eviction, -ENOSPC =3D skip this place) is a clean abstraction. The d= oc comment on `ttm_bo_alloc_at_place()` clearly documents the return values. The `-EAGAIN` to `-EBUSY`/`-ENOSPC` translation is well-commented: ```c /* * -EAGAIN means the charge failed, which we treat like an * allocation failure. */ if (ret =3D=3D -EAGAIN) return may_evict ? -EBUSY : -ENOSPC; ``` Reviewed-by from Tvrtko is present. The `return;` bug may have been introdu= ced after that review. --- Generated by Claude Code Patch Reviewer