Claude review: drm/shmem_helper: Make sure PMD entries get the writeable upgrade

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**The core fix is correct.** Passing `vmf->flags & FAULT_FLAG_WRITE` to `vmf_insert_pfn_pmd()` and recording dirty/mkwrite in the PMD path addresses the issue introduced by commit 28e3918179aa.

**Bug: Error handling regression in `drm_gem_shmem_pfn_mkwrite()`.**

The original code returned `VM_FAULT_SIGBUS` on the error path:

```c
if (drm_WARN_ON(obj->dev, !shmem->pages || page_offset >= num_pages))
    return VM_FAULT_SIGBUS;
```

The new `drm_gem_shmem_record_mkwrite()` is a `void` function that simply returns on the WARN path:

```c
static void drm_gem_shmem_record_mkwrite(struct vm_fault *vmf)
{
    ...
    if (drm_WARN_ON(obj->dev, !shmem->pages || page_offset >= num_pages))
        return;
    ...
}
```

And `drm_gem_shmem_pfn_mkwrite()` now unconditionally returns 0 (success):

```c
static vm_fault_t drm_gem_shmem_pfn_mkwrite(struct vm_fault *vmf)
{
    drm_gem_shmem_record_mkwrite(vmf);
    return 0;
}
```

So if the WARN fires (pages are NULL or offset is out of range), the old code signalled `VM_FAULT_SIGBUS` to userspace, but the new code silently succeeds. This should be preserved — either by making `drm_gem_shmem_record_mkwrite()` return a `vm_fault_t`, or by keeping the validation inline in `drm_gem_shmem_pfn_mkwrite()`.

**Minor: Comment style.** The multi-line comment at the PMD insertion site doesn't follow kernel style:

```c
			/* Unlike PTEs which are automatically upgraded to
			 * writeable entries, the PMD upgrades go through
```

Kernel style uses:

```c
			/*
			 * Unlike PTEs which are automatically upgraded to
			 * writeable entries, the PMD upgrades go through
```

**Locking question.** The author raises this themselves in the cover letter. `drm_gem_shmem_record_mkwrite()` accesses `shmem->pages[page_offset]` without holding `dma_resv_lock`. In the PMD path (called from `drm_gem_shmem_fault()`), the lock is already held, so it's safe. In the PTE `.pfn_mkwrite()` path, the lock is not held — but this was already the case before the patch, so it's not a regression. Still, it would be worth confirming that `shmem->pages` cannot be freed while an mmap exists (it shouldn't be, due to the `pages_use_count` refcount taken in `drm_gem_shmem_mmap()`/`vm_open()`).

**Summary:** The fix is logically correct and well-motivated. The `VM_FAULT_SIGBUS` -> silent success error handling change should be fixed before merging.

---
Generated by Claude Code Patch Reviewer