From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: media: videobuf2: Set vma_flags in vb2_dma_sg_mmap Date: Mon, 16 Feb 2026 06:42:02 +1000 Message-ID: In-Reply-To: <20260215-media-vb2-dma-sg-v1-1-91b6aa6c1cec@jannau.net> References: <20260215-media-vb2-dma-sg-v1-1-91b6aa6c1cec@jannau.net> <20260215-media-vb2-dma-sg-v1-1-91b6aa6c1cec@jannau.net> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 =E2=80=94 after `vm_map_pages()` succeeds= and before setting up `vm_ops` / `vm_private_data`, exactly mirroring the pa= ttern in `vb2_dma_contig_mmap()` at `videobuf2-dma-contig.c:296`. The `vm_fla= gs_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()` wa= s added later, the omission of these flags has been present since the allocat= or's introduction, and the flags are independently correct for this type of b= uffer (preventing userspace from expanding or dumping GPU-backed mappings). --- Generated by Claude Code Patch Reviewer