From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: cgroup/dmem: allow max to be set below current usage Date: Sun, 22 Mar 2026 04:08:56 +1000 Message-ID: In-Reply-To: <20260319-dmem_max_ebusy-v2-3-b5ce97205269@igalia.com> References: <20260319-dmem_max_ebusy-v2-0-b5ce97205269@igalia.com> <20260319-dmem_max_ebusy-v2-3-b5ce97205269@igalia.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 `-EB= USY` when usage exceeds the new max. The return value was being silently di= scarded by `set_resource_max()` (which returns `void`), causing the write t= o 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 i= s allowed One consideration: `page_counter_set_max` was designed with the read-swap-r= ead pattern to ensure coherency with `page_counter_try_charge`. By doing a = bare `xchg` without the subsequent usage check, there's a theoretical windo= w 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 m= emcg's `memory.max` write path (which also just does `WRITE_ONCE` on the ma= x), and is acceptable =E2=80=94 the charge will be caught on the next attem= pt. This is fine. --- Generated by Claude Code Patch Reviewer