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/panthor: Track the number of mmap on a BO Date: Tue, 31 Mar 2026 17:24:47 +1000 Message-ID: In-Reply-To: <20260330094848.2169422-9-boris.brezillon@collabora.com> References: <20260330094848.2169422-1-boris.brezillon@collabora.com> <20260330094848.2169422-9-boris.brezillon@collabora.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review The mmap_count tracking with `refcount_t` is well-handled: - `panthor_gem_mmap`: double-checked init (try inc outside lock, then inside lock) - `panthor_gem_vm_open`: `refcount_inc_not_zero` with WARN if it fails (should never fail since the VMA is being duplicated from an existing one) - `panthor_gem_vm_close`: try `refcount_dec_not_one` first (fast path), then take resv lock for the last-reference case The `panthor_gem_vm_close` pattern is somewhat unusual - doing `refcount_dec_not_one()` then `refcount_dec_and_test()` under lock. This is safe because `refcount_dec_not_one` returns false if count was 1 (doesn't decrement), and then under the lock `refcount_dec_and_test` handles the actual last-reference case. A concurrent `panthor_gem_mmap` could bump the count between the two, which is fine - the `dec_and_test` would then not reach zero. No issues. --- Generated by Claude Code Patch Reviewer