From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Zero page->private when freeing pages Date: Tue, 24 Feb 2026 10:52:52 +1000 Message-ID: In-Reply-To: <20260223032641.1859381-1-ziy@nvidia.com> References: <20260223032641.1859381-1-ziy@nvidia.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: Zero page->private when freeing pages Author: Zi Yan Patches: 22 Reviewed: 2026-02-24T10:52:52.290001 --- This series from Zi Yan aims to enforce the invariant that `page->private` must be zero when a page is returned to the page allocator. Patches 1-9 fix individual subsystems that store data in `page->private` but don't zero it before freeing. Patch 10 restores a check in folio splitting, and patch 11 adds a `VM_WARN_ON_ONCE` in `__free_pages_prepare()` to catch any remaining violators. The approach is reasonable and comes from a discussion with David Hildenbrand. However, there is a bug in patch 1 (wrong loop variable causing a NULL pointer dereference), and patch 3 (drm/ttm) only handles one of the two freeing paths. Patch 11 removes the existing `page->private = 0` safety net in the page allocator, replacing it with only a warning. This means any missed caller will now silently leak stale private data to the next page consumer, which is a correctness regression compared to the previous defensive clearing. The series also has a general weakness: the commit messages for patches 1-9 are all nearly identical ("This prepares for upcoming checks in page freeing path.") and don't explain what the subsystem was storing in `page->private` or why it was non-zero. That context would be valuable for reviewers. --- Generated by Claude Code Patch Reviewer