Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Critical] Direct dereference of `bo->resource` without a NULL check in `ttm_bo_setup_export` causes a kernel panic when exporting pipeline-gutted BOs. --
commit dc7f000aeb70e2be50c58ca89d0162684ebb0574 Author: Dave Airlie <[email protected]> ttm: hook up memcg placement flags. This commit adds a placement flag to request memory cgroup accounting for system memory allocations. It updates various callers of ttm_bo_populate() to pass this flag by checking the placement flags of the buffer object's resource. > 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] Can this dereference a NULL pointer if the buffer object has been pipeline-gutted? Under memory pressure, TTM eviction logic may pipeline-gut the BO via ttm_bo_pipeline_gutting(), which frees the resource and sets bo->resource to NULL. If userspace then invokes the DMA-BUF export ioctl on this gutted BO, the driver's export callback (like amdgpu_gem_prime_export) can call ttm_bo_setup_export() without re-validating the BO. This results in an unconditional dereference of the NULL pointer when evaluating bo->resource->placement. Would it be safer to check if bo->resource is valid before checking its placement flags? > ttm_bo_unreserve(bo); > return ret; > } -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=6
