From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/gem-shmem: Track folio accessed/dirty status in mmap
Date: Wed, 11 Feb 2026 17:04:34 +1000 [thread overview]
Message-ID: <review-patch5-20260209133241.238813-6-tzimmermann@suse.de> (raw)
In-Reply-To: <20260209133241.238813-6-tzimmermann@suse.de>
Patch Review
**Review:**
Core functionality: adds folio tracking in mmap path.
**Accessed tracking:**
```c
+ if (likely(!(ret & VM_FAULT_ERROR)))
+ folio_mark_accessed(folio);
```
This marks the folio as accessed on successful page fault. Good for LRU management.
**Issue 1 - PMD vs PTE tracking:**
The `folio_mark_accessed()` is called regardless of whether a PMD or PTE was inserted. For PMD mappings (huge pages), marking the folio accessed is correct since the whole folio was mapped. Good.
**Dirty tracking:**
```c
+static vm_fault_t drm_gem_shmem_pfn_mkwrite(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct drm_gem_object *obj = vma->vm_private_data;
+ struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
+ pgoff_t page_offset = vmf->pgoff - vma->vm_pgoff;
+ struct page *page = shmem->pages[page_offset];
+ struct folio *folio = page_folio(page);
+
+ file_update_time(vma->vm_file);
+ folio_mark_dirty(folio);
+
+ return 0;
+}
```
**Issue 2 - Missing locking:**
The `pfn_mkwrite` handler accesses `shmem->pages[page_offset]` without holding `obj->resv` lock. Compare with the `fault` handler which does:
```c
dma_resv_lock(obj->resv, NULL);
page = pages[page_offset];
...
dma_resv_unlock(obj->resv);
```
**This is a race condition.** Between the time the page is faulted and mkwrite is called, the pages array could be freed/reallocated. The `pfn_mkwrite` needs to:
1. Lock `obj->resv`
2. Verify `shmem->pages` is still valid
3. Verify the page at `page_offset` is still valid
4. Mark dirty
5. Unlock
**Issue 3 - PMD mkwrite:**
As mentioned in PATCH 4, PMDs are inserted read-only:
```c
vmf_insert_pfn_pmd(vmf, pfn, false); // false = read-only
```
But `pfn_mkwrite` only handles PTE granularity (it uses `vmf->pgoff` to get a single page). **There's no `huge_fault` or PMD-specific mkwrite handler.** This means:
1. PMD inserted read-only
2. Write occurs
3. PMD is split by kernel into PTEs (expensive!)
4. PTE mkwrite called
This defeats the purpose of huge page mappings for write-heavy workloads. Should either:
- Insert PMDs with write permission if mapping allows
- Implement PMD-granularity mkwrite
**Issue 4 - File timestamp update:**
```c
file_update_time(vma->vm_file);
```
This is called on every write fault. For frequently-written pages, this could cause significant overhead. Traditional page cache code only updates time periodically, not on every mkwrite. Consider using `file_modified()` with appropriate checks, or rate-limiting updates.
**Issue 5 - Return value:**
```c
return 0;
```
The function returns 0 (success) unconditionally. What if `folio_mark_dirty()` fails or the folio is in a bad state? Should validate folio state before marking dirty.
**Verdict:** ⚠ Missing locking (critical bug), PMD handling incomplete, potential performance issues
---
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-02-11 7:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 13:27 [PATCH v3 0/6] drm/gem-shmem: Track page accessed/dirty status Thomas Zimmermann
2026-02-09 13:27 ` [PATCH v3 1/6] drm/gem-shmem: Use obj directly where appropriate in fault handler Thomas Zimmermann
2026-02-09 14:10 ` Boris Brezillon
2026-02-11 7:04 ` Claude review: " Claude Code Review Bot
2026-02-09 13:27 ` [PATCH v3 2/6] drm/gem-shmem: Test for existence of page in mmap " Thomas Zimmermann
2026-02-09 14:10 ` Boris Brezillon
2026-02-11 7:04 ` Claude review: " Claude Code Review Bot
2026-02-09 13:27 ` [PATCH v3 3/6] drm/gem-shmem: Return vm_fault_t from drm_gem_shmem_try_map_pmd() Thomas Zimmermann
2026-02-11 7:04 ` Claude review: " Claude Code Review Bot
2026-02-09 13:27 ` [PATCH v3 4/6] drm/gem-shmem: Refactor drm_gem_shmem_try_map_pmd() Thomas Zimmermann
2026-02-09 14:25 ` Boris Brezillon
2026-02-11 7:04 ` Claude review: " Claude Code Review Bot
2026-02-09 13:27 ` [PATCH v3 5/6] drm/gem-shmem: Track folio accessed/dirty status in mmap Thomas Zimmermann
2026-02-09 14:23 ` Boris Brezillon
2026-02-09 14:46 ` Thomas Zimmermann
2026-02-09 15:01 ` Boris Brezillon
2026-02-11 7:04 ` Claude Code Review Bot [this message]
2026-02-09 13:27 ` [PATCH v3 6/6] drm/gem-shmem: Track folio accessed/dirty status in vmap Thomas Zimmermann
2026-02-11 7:04 ` Claude review: " Claude Code Review Bot
2026-02-11 7:04 ` Claude review: drm/gem-shmem: Track page accessed/dirty status 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-patch5-20260209133241.238813-6-tzimmermann@suse.de \
--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