public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: mm/page_alloc: check page->private upon page free
Date: Tue, 24 Feb 2026 10:52:54 +1000	[thread overview]
Message-ID: <review-patch11-20260223032641.1859381-12-ziy@nvidia.com> (raw)
In-Reply-To: <20260223032641.1859381-12-ziy@nvidia.com>

Patch Review

> -	page->private = 0;
> +	VM_WARN_ON_ONCE(page->private);

This removes the safety-net zeroing of `page->private` for the head page and replaces it with only a warning. The loop body for sub-pages also only adds a warning:

> 			(page + i)->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;
> +			VM_WARN_ON_ONCE((page + i)->private);

Two concerns:

First, `VM_WARN_ON_ONCE` only fires in debug kernels (when `CONFIG_DEBUG_VM` is set). In production kernels without this config, the `VM_WARN_ON_ONCE` compiles to nothing, meaning the old `page->private = 0` is simply deleted with no replacement. Any subsystem missed by patches 1-9 would silently leave stale data in private, potentially affecting the next page consumer. This is a correctness regression compared to the previous unconditional clearing.

Second, this is `WARN_ON_ONCE`, so only the first violation will be reported. If there are multiple subsystems that still need fixing, only one will be visible per boot.

The cover letter acknowledges the author "only tested part of" the subsystem fixes. Given that, removing the safety net in `__free_pages_prepare` seems premature. Would it be safer to keep the `page->private = 0` and add a `VM_WARN_ON_ONCE` check *before* the zeroing? That would catch violators while still maintaining the safety net:

```c
VM_WARN_ON_ONCE(page->private);
page->private = 0;
```

---
Generated by Claude Code Patch Reviewer

  reply	other threads:[~2026-02-24  0:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23  3:26 [PATCH v1 00/11] Zero page->private when freeing pages Zi Yan
2026-02-23  3:26 ` [PATCH v1 01/11] relay: zero " Zi Yan
2026-02-23 14:45   ` Usama Arif
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 02/11] mm/slub: " Zi Yan
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 03/11] drm/ttm: " Zi Yan
2026-02-23 10:43   ` Christian König
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 04/11] blk-mq: " Zi Yan
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 05/11] watch_queue: " Zi Yan
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 06/11] binder: " Zi Yan
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 07/11] null_blk: " Zi Yan
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 08/11] percpu: " Zi Yan
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 09/11] erofs: " Zi Yan
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 10/11] mm/huge_memory: add page->private check back in __split_folio_to_order() Zi Yan
2026-02-24  0:52   ` Claude review: " Claude Code Review Bot
2026-02-23  3:26 ` [PATCH v1 11/11] mm/page_alloc: check page->private upon page free Zi Yan
2026-02-24  0:52   ` Claude Code Review Bot [this message]
2026-02-23  4:28 ` [PATCH v1 00/11] Zero page->private when freeing pages Matthew Wilcox
2026-02-23  9:36   ` David Hildenbrand (Arm)
2026-02-23  8:40 ` [syzbot ci] " syzbot ci
     [not found] ` <aZxaIEFZr2NvO2eQ@infradead.org>
2026-02-23 14:00   ` [PATCH v1 00/11] " Zi Yan
     [not found]     ` <aZxeLmNyKKTrkSzn@infradead.org>
2026-02-23 14:11       ` Zi Yan
2026-02-23 14:06   ` Christian König
2026-02-23 14:14     ` David Hildenbrand (Arm)
2026-02-23 15:22       ` Christian König
2026-02-23 15:27         ` David Hildenbrand (Arm)
2026-02-24  0:52 ` Claude review: " Claude Code Review Bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=review-patch11-20260223032641.1859381-12-ziy@nvidia.com \
    --to=claude-review@example.com \
    --cc=dri-devel-reviews@example.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox