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 <[email protected]> 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/[email protected]?part=6
