[PATCH] media: videobuf2: Set vma_flags in vb2_dma_sg_mmap

[PATCH] media: videobuf2: Set vma_flags in vb2_dma_sg_mmap

[Janne Grunau]

vb2_dma_contig sets VMA flags VM_DONTEXPAND and VM_DONTDUMP and I do not
see a reason why vb2_dma_sg should behave differently. This avoids
hitting `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));` in
drm_gem_mmap_obj() during mmap() of an imported dma-buf from the out of
tree Apple ISP camera capture driver which uses vb2_dma_sg_memops.

gst-launch-1.0 v4l2src ! gtk4paintablesink

[   38.201528] ------------[ cut here ]------------
[   38.202135] WARNING: CPU: 7 PID: 2362 at drivers/gpu/drm/drm_gem.c:1144 drm_gem_mmap_obj+0x1f8/0x210
[   38.203278] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer
snd_seq snd_seq_device uinput nf_conntrack_netbios_ns
nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib
nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep
nls_ascii i2c_dev loop fuse dm_multipath nfnetlink brcmfmac_wcc
hid_magicmouse hci_bcm4377 brcmfmac brcmutil bluetooth ecdh_generic
cfg80211 ecc btrfs xor xor_neon rfkill hid_apple raid6_pq joydev
aop_als apple_nvmem_spmi industrialio snd_soc_aop apple_z2
snd_soc_cs42l84 tps6598x snd_soc_tas2764 macsmc_reboot spi_nor
macsmc_hwmon rtc_macsmc gpio_macsmc macsmc_power regmap_spmi
macsmc_input dockchannel_hid panel_summit appledrm nvme_apple dwc3
snd_soc_macaudio drm_client_lib nvme_core phy_apple_atc hwmon
apple_sart apple_dockchannel macsmc apple_rtkit_helper
spmi_apple_controller aop apple_wdt mfd_core nvmem_apple_efuses
pinctrl_apple_gpio apple_isp apple_dcp videobuf2_dma_sg mux_core
spi_apple
[   38.203300]  videobuf2_memops i2c_pasemi_platform snd_soc_apple_mca videobuf2_v4l2 videodev clk_apple_nco videobuf2_common snd_pcm_dmaengine adpdrm asahi apple_admac adpdrm_mipi drm_dma_helper pwm_apple i2c_pasemi_core drm_display_helper mc cec apple_dart ofpart apple_soc_cpufreq leds_pwm phram
[   38.217677] CPU: 7 UID: 1000 PID: 2362 Comm: gst-launch-1.0 Tainted: G        W           6.17.6+ #asahi-dev PREEMPT(full)
[   38.219040] Tainted: [W]=WARN
[   38.219398] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)
[   38.220213] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[   38.221088] pc : drm_gem_mmap_obj+0x1f8/0x210
[   38.221643] lr : drm_gem_mmap_obj+0x78/0x210
[   38.222178] sp : ffffc0008dc678e0
[   38.222579] x29: ffffc0008dc678e0 x28: 0000000000042a97 x27: ffff8000b701b480
[   38.223465] x26: 00000000000000fb x25: ffffc0008dc67d20 x24: ffffc0008dc67968
[   38.224402] x23: ffff8000e3ca5600 x22: ffff8000265b7800 x21: ffff80003000c0c0
[   38.225279] x20: 0000000000000000 x19: ffff8000b68c5200 x18: ffffc0008dc67968
[   38.226151] x17: 0000000000000000 x16: 0000000000000000 x15: ffffc000810a30a8
[   38.227042] x14: 00007fff637effff x13: 00005555de91ffff x12: 00007fff63293fff
[   38.227942] x11: 0000000000000000 x10: ffff8000184ecf08 x9 : ffffc0007a1900c8
[   38.228824] x8 : ffffc0008dc67968 x7 : 0000000000000012 x6 : ffffc0015cf1c000
[   38.229703] x5 : ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 : 0000000000000038
[   38.230607] x2 : 0000000000000003 x1 : 0000000000000003 x0 : 00000000100000fb
[   38.231488] Call trace:
[   38.231806]  drm_gem_mmap_obj+0x1f8/0x210 (P)
[   38.232342]  drm_gem_mmap+0x140/0x260
[   38.232813]  __mmap_region+0x488/0x9a0
[   38.233277]  mmap_region+0xd0/0x148
[   38.233703]  do_mmap+0x350/0x5c0
[   38.234148]  vm_mmap_pgoff+0x14c/0x200
[   38.234612]  ksys_mmap_pgoff+0x150/0x208
[   38.235107]  __arm64_sys_mmap+0x34/0x50
[   38.235611]  invoke_syscall+0x50/0x120
[   38.236075]  el0_svc_common.constprop.0+0x48/0xf0
[   38.236680]  do_el0_svc+0x24/0x38
[   38.237113]  el0_svc+0x38/0x168
[   38.237507]  el0t_64_sync_handler+0xa0/0xe8
[   38.238034]  el0t_64_sync+0x198/0x1a0
[   38.238491] ---[ end trace 0000000000000000 ]---

There were discussions in [1] at the end of 2023 that mmap() on imported
dma-bufs should not be supported but as of v6.17 drm_gem_shmem_mmap() in
drm_gem_shmem_helper.c still supports it.
This might affect all gpu or accel drivers using drm_gem_shmem_mmap() or
the wrapper drm_gem_shmem_object_mmap().

[1] https://lore.kernel.org/dri-devel/bc7f7844-0aa3-4802-b203-69d58e8be2fa@linux.intel.com/

Cc: stable@vger.kernel.org
Fixes: 5ba3f757f059 ("[media] v4l: videobuf2: add DMA scatter/gather allocator")
Signed-off-by: Janne Grunau <j@jannau.net>
---
included DRM maintainers due to warning triggered from DRM code.
---
 drivers/media/common/videobuf2/videobuf2-dma-sg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index b3bf2173c14e1b3bedb8ab0bd60c889a0b97cbe3..7c30731cb9a57bebb3cf418e627e7c9f09ba8642 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -345,6 +345,7 @@ static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma)
 		return err;
 	}
 
+	vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP);
 	/*
 	 * Use common vm_area operations to track buffer refcount.
 	 */

---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260215-media-vb2-dma-sg-0fa33fdafdde

Best regards,
-- 
Janne Grunau <j@jannau.net>

Claude review: media: videobuf2: Set vma_flags in vb2_dma_sg_mmap

[Claude Code Review Bot]

Overall Series Review

Subject: media: videobuf2: Set vma_flags in vb2_dma_sg_mmap
Author: Janne Grunau <j@jannau.net>
Patches: 1
Reviewed: 2026-02-16T06:42:02.240640

---

This is a single-patch series that adds `VM_DONTEXPAND | VM_DONTDUMP` flags to the `vb2_dma_sg_mmap()` function in the videobuf2 DMA scatter/gather allocator. The `vb2_dma_contig` allocator already sets these flags in its mmap handler, and the vmalloc allocator sets `VM_DONTEXPAND`. The missing flags cause a `WARN_ON` in `drm_gem_mmap_obj()` when a DRM driver imports a dma-buf from a V4L2 device that uses `vb2_dma_sg_memops` and the buffer is subsequently mmapped through the DRM GEM path.

The fix is straightforward, correct, and consistent with the existing pattern in the sibling allocators. The commit message is thorough — it explains the problem, provides the call trace, references prior discussion about the broader question of mmap on imported dma-bufs, and includes appropriate Fixes and Cc: stable tags.

No issues found.

---
Generated by Claude Code Patch Reviewer

Claude review: media: videobuf2: Set vma_flags in vb2_dma_sg_mmap

[Claude Code Review Bot]

Patch Review

> +	vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP);
>  	/*
>  	 * Use common vm_area operations to track buffer refcount.
>  	 */

No issues. The placement is correct — after `vm_map_pages()` succeeds and before setting up `vm_ops` / `vm_private_data`, exactly mirroring the pattern in `vb2_dma_contig_mmap()` at `videobuf2-dma-contig.c:296`. The `vm_flags_set()` API is the correct accessor (rather than directly manipulating `vma->vm_flags`).

The `Fixes:` tag pointing to the original commit that introduced `vb2_dma_sg` (`5ba3f757f059`) is reasonable. While the WARN_ON in `drm_gem_mmap_obj()` was added later, the omission of these flags has been present since the allocator's introduction, and the flags are independently correct for this type of buffer (preventing userspace from expanding or dumping GPU-backed mappings).

---
Generated by Claude Code Patch Reviewer