Re: [PATCH 06/10] ttm: hook up memcg placement flags.

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Dereferencing `bo->resource` in `ttm_bo_setup_export()` without checking for NULL causes a kernel panic if the buffer object has been gutted.
--

commit 55aef0c5658ae86fbf245de25768c668ff9edb05
Author: Dave Airlie <airlied@redhat.com>

ttm: hook up memcg placement flags.

This commit adds a placement flag to request that a buffer object with
this flag is accounted for memcg if it's a system memory allocation.

> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8e38c6c5c82ef..54ee9d4e7a139 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
[ ... ]
> @@ -1296,7 +1296,7 @@ int ttm_bo_setup_export(struct ttm_buffer_object *bo,
>  	if (ret != 0)
>  		return ret;
>  
> -	ret = ttm_bo_populate(bo, false, ctx);
> +	ret = ttm_bo_populate(bo, bo->resource->placement & TTM_PL_FLAG_MEMCG, ctx);

[Severity: Critical]
Does this code unconditionally dereference bo->resource?

If a buffer object has been gutted (evicted without a fallback placement),
bo->resource will be NULL.

Could a user-space application trigger a kernel panic by exporting such a
gutted buffer via the DRM_IOCTL_PRIME_HANDLE_TO_FD IOCTL, which ultimately
calls ttm_bo_setup_export() on the DMABUF export path?

>  	ttm_bo_unreserve(bo);
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706052330.1110909-1-airlied@gmail.com?part=6