When the mmap function was converted from a file op to a GEM object
function in commit f5ca8eb6f9bd ("drm/cma-helper: Implement mmap as GEM
CMA object functions") some VM flags were not lifted from drm_gem_mmap():

  - VM_IO
  - VM_DONTEXPAND
  - VM_DONTDUMP

VM_DONTEXPAND was added back in commit 59f39bfa6553 ("drm/cma-helper:
Set VM_DONTEXPAND for mmap"). VM_IO doesn't make sense since these are
memory buffers, while "IO tells people not to look at these pages
(accesses can have side effects)".

Add back VM_DONTDUMP. This matches the behavior of most other GEM
implementations.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/gpu/drm/drm_gem_dma_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
index ecb9746f4da8..1911bf6a6a3e 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -534,7 +534,7 @@ int drm_gem_dma_mmap(struct drm_gem_dma_object *dma_obj, struct vm_area_struct *
 	 * the whole buffer.
 	 */
 	vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
-	vm_flags_mod(vma, VM_DONTEXPAND, VM_PFNMAP);
+	vm_flags_mod(vma, VM_DONTDUMP | VM_DONTEXPAND, VM_PFNMAP);
 
 	if (dma_obj->map_noncoherent) {
 		vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
-- 
2.53.0.851.ga537e3e6e9-goog

On Tue, 17 Mar 2026 12:00:32 +0800, Chen-Yu Tsai wrote:
> When the mmap function was converted from a file op to a GEM object
> function in commit f5ca8eb6f9bd ("drm/cma-helper: Implement mmap as GEM
> CMA object functions") some VM flags were not lifted from drm_gem_mmap():
> 
>   - VM_IO
>   - VM_DONTEXPAND
>   - VM_DONTDUMP
> 
> [...]

Applied to drm-misc-next in drm-misc, thanks!

[1/1] drm/gem-dma: set VM_DONTDUMP for mmap
      commit: e3eb0e70815cc02ea15298818e37d8b0a0930ab1

Best regards,
-- 
Chen-Yu Tsai <wenst@chromium.org>

Am 17.03.26 um 05:00 schrieb Chen-Yu Tsai:
> When the mmap function was converted from a file op to a GEM object
> function in commit f5ca8eb6f9bd ("drm/cma-helper: Implement mmap as GEM
> CMA object functions") some VM flags were not lifted from drm_gem_mmap():
>
>    - VM_IO
>    - VM_DONTEXPAND
>    - VM_DONTDUMP
>
> VM_DONTEXPAND was added back in commit 59f39bfa6553 ("drm/cma-helper:
> Set VM_DONTEXPAND for mmap"). VM_IO doesn't make sense since these are
> memory buffers, while "IO tells people not to look at these pages
> (accesses can have side effects)".
>
> Add back VM_DONTDUMP. This matches the behavior of most other GEM
> implementations.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>

I think it makes sense to not dump these buffers.

Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>

> ---
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> ---
>   drivers/gpu/drm/drm_gem_dma_helper.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
> index ecb9746f4da8..1911bf6a6a3e 100644
> --- a/drivers/gpu/drm/drm_gem_dma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_dma_helper.c
> @@ -534,7 +534,7 @@ int drm_gem_dma_mmap(struct drm_gem_dma_object *dma_obj, struct vm_area_struct *
>   	 * the whole buffer.
>   	 */
>   	vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
> -	vm_flags_mod(vma, VM_DONTEXPAND, VM_PFNMAP);
> +	vm_flags_mod(vma, VM_DONTDUMP | VM_DONTEXPAND, VM_PFNMAP);
>   
>   	if (dma_obj->map_noncoherent) {
>   		vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)