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/pagemap: Unlock and put folios when possible Date: Fri, 13 Mar 2026 14:02:31 +1000 Message-ID: In-Reply-To: <20260312151726.1779566-2-francois.dugast@intel.com> References: <20260312151726.1779566-1-francois.dugast@intel.com> <20260312151726.1779566-2-francois.dugast@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Clean conversion from page-level to folio-level unlock/put. The logic change from `++i` increment with `continue` to bottom-of-loop `i += NR_PAGES(order)` with `goto next` is correct. One subtlety worth verifying: when `!migrate_pfn[i]`, `order` remains 0 so `NR_PAGES(0) = 1`, correctly advancing by one entry. This is correct. ```c + if (!migrate_pfn[i]) + goto next; ... +next: + i += NR_PAGES(order); ``` The `migrate_pfn[i] = 0` assignment after the folio put is only done for the head entry. For a multi-page folio, the tail entries in `migrate_pfn[]` are not zeroed. This matches the existing behavior since the loop now skips over tail entries via `NR_PAGES(order)`, but callers that later iterate `migrate_pfn[]` linearly (without folio awareness) could see stale non-zero entries for tail pages. This should be fine since callers are being converted to folio-aware iteration in the rest of the series. **Verdict: Looks good.** --- --- Generated by Claude Code Patch Reviewer