Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/msm: memory leak and LRU invariant violation due to is_resident() relying only on sgt --
commit 5c4dfee34fe56ce4eb175d5b53ce5d68a5bafe60 Author: Rob Clark <[email protected]> drm/msm/gem: Stop calling get_pages() for imported dma-bufs This commit stops calling get_pages() for imported dma-bufs and uses the sgt instead of pages to determine if an object is resident. > diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h > index d7df016b1f272..d8ec696d89d74 100644 > --- a/drivers/gpu/drm/msm/msm_gem.h > +++ b/drivers/gpu/drm/msm/msm_gem.h > @@ -425,7 +425,7 @@ static inline bool is_unevictable(struct msm_gem_object > *msm_obj) > /* Are backing pages/sgt allocated? */ > static inline bool is_resident(struct msm_gem_object *msm_obj) > { > - return !!msm_obj->pages; > + return !!msm_obj->sgt; > } [Severity: High] Can this cause a memory leak and trigger a WARN_ON? If get_pages() successfully allocates msm_obj->pages but fails at drm_prime_pages_to_sg(), it returns an error but retains msm_obj->pages while msm_obj->sgt is NULL. With is_resident() now relying strictly on sgt, this partially backed object is considered non-resident. If userspace retries pinning the object, get_pages() sees msm_obj->pages is already populated, returns success, and increments pin_count while sgt remains NULL. A subsequent unpin or madvise will call update_lru_locked(), which uses is_resident(): drivers/gpu/drm/msm/msm_gem.c:update_lru_locked() { ... if (!is_resident(msm_obj)) { GEM_WARN_ON(msm_obj->pin_count); drm_gem_lru_move_tail_locked(&priv->lru.unbacked, obj); } ... } Because is_resident() returns false, the object is placed in the unbacked LRU list, causing a memory leak since the shrinker only scans dontneed and willneed lists. It will also trigger the GEM_WARN_ON splat. -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5
