On Fri, May 08, 2026 at 12:40:48PM +0200, Boris Brezillon wrote:
> The following race can currently happen:
>
> | Thread 0 in `drm_gem_lru_scan` | Thread 1 in
> `drm_gem_object_release` |
> | - | -
> |
> | move obj1 with refcount==0 to `still_in_lru` |
> |
> | move obj2 with refcount!=0 to `still_in_lru` |
> |
> | mutex_unlock |
> |
> | shrink obj2 |
> |
> | | lru = obj1->lru; //
> `still_in_lru` |
> | mutex_lock |
> |
> | move obj1 back to the original lru |
> |
> | mutex_unlock |
> |
> | return |
> |
> | | dereference `still_in_lru`
> |
>
> Move the drm_gem_lru_move_tail_locked() after the
> kref_get_unless_zero() check so that we don't end up with a
> vanishing LRU when we hit drm_gem_object_release(). We also need to
> remove the skipped object from its LRU, otherwise we'll keep hitting
> it on subsequent loop iterations until it's actually removed from the
> list in the drm_gem_release().
>
> Fixes: e7c2af13f811 ("drm/gem: Add LRU/shrinker helper")
> Reported-by: Chia-I Wu <[email protected]>
> Closes: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/86
> Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Liviu Dudau <[email protected]>
> ---
> drivers/gpu/drm/drm_gem.c | 34 ++++++++++++++++++++++++++++------
> 1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index fca42949eb2b..0e087c770883 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1573,11 +1573,31 @@ drm_gem_lru_remove(struct drm_gem_object *obj)
> {
> struct drm_gem_lru *lru = obj->lru;
>
> + /*
> + * We do the lru != NULL check without the lru->lock held, which
> + * means we might end up with a stale lru value by the time the
> + * lock is acquired.
> + *
> + * This is deemed safe because:
> + * 1. the LRU is assumed to outlive any GEM object it was attached
> + * (LRUs are usually bound to a drm_device). So even if obj->lru
> + * has become NULL, it still point to a valid object that can
> + * safely be dereferenced to get the lock.
> + *
> + * 2. all LRUs a GEM object might be attached to must share the same
> + * lock (lock that's usually part of the driver-specific device
> + * object), so taking the lock on the 'old' LRU is equivalent
> + * to taking it on the new one (if any)
I like the description, but I think it's worth merging the later comment around
the second check here as that is basically the whole "belt and braces" mechanism
for ensuring correctness.
Best regards,
Liviu
> + */
> if (!lru)
> return;
>
> mutex_lock(lru->lock);
> - drm_gem_lru_remove_locked(obj);
> + /* Check a second time with the lock held to make sure we're not racing
> + * with another drm_gem_lru_remove[_locked]() call.
> + */
> + if (obj->lru)
> + drm_gem_lru_remove_locked(obj);
> mutex_unlock(lru->lock);
> }
> EXPORT_SYMBOL(drm_gem_lru_remove);
> @@ -1660,15 +1680,17 @@ drm_gem_lru_scan(struct drm_gem_lru *lru,
> if (!obj)
> break;
>
> - drm_gem_lru_move_tail_locked(&still_in_lru, obj);
> -
> /*
> * If it's in the process of being freed, gem_object->free()
> - * may be blocked on lock waiting to remove it. So just
> - * skip it.
> + * may be blocked on lock waiting to remove it. So just remove
> + * it from its current LRU and skip it.
> */
> - if (!kref_get_unless_zero(&obj->refcount))
> + if (!kref_get_unless_zero(&obj->refcount)) {
> + drm_gem_lru_remove_locked(obj);
> continue;
> + }
> +
> + drm_gem_lru_move_tail_locked(&still_in_lru, obj);
>
> /*
> * Now that we own a reference, we can drop the lock for the
>
> --
> 2.54.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
