From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/ttm: zero page->private when freeing pages
Date: Tue, 24 Feb 2026 10:52:52 +1000
Message-ID: <review-patch3-20260223032641.1859381-4-ziy@nvidia.com>
In-Reply-To: <20260223032641.1859381-4-ziy@nvidia.com>
References: <20260223032641.1859381-1-ziy@nvidia.com> <20260223032641.1859381-4-ziy@nvidia.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

> 	if (!pool || !ttm_pool_uses_dma_alloc(pool)) {
> +		set_page_private(p, 0);
> 		__free_pages(p, order);
> 		return;
> 	}

This only handles the non-DMA allocation path. Looking at `ttm_pool_free_page`, the DMA allocation path (the else branch) also stores a `struct ttm_pool_dma *` pointer in `p->private`:

```c
dma = (void *)p->private;
vaddr = (void *)(dma->vaddr & PAGE_MASK);
dma_free_attrs(pool->dev, ..., vaddr, dma->addr, attr);
kfree(dma);
```

After `dma_free_attrs`, the underlying pages are freed with `page->private` still pointing to the (now kfree'd) DMA metadata. If those pages eventually reach `__free_pages_prepare` (which many DMA implementations will do), the check added by patch 11 would fire. Should `set_page_private(p, 0)` be added before the `dma_free_attrs` call in the DMA path as well?

Christian Koenig acked the patch but also asked why `__free_pages()` doesn't just do the zeroing itself -- which is a reasonable question given the approach taken in patch 11.

---
Generated by Claude Code Patch Reviewer