Re: [PATCH] drm/ttm: fix double lock on glob->lru_lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



NAK,  ttm_bo_cleanup_refs() is dropping the lock.

Your backtrace is cause by an issue I've fixed this morning on amd-staging-drm-next.

Regards,
Christian.

Am 22.12.2017 um 19:03 schrieb Colin King:
From: Colin Ian King <colin.king@xxxxxxxxxxxxx>

Lock glob->lru_lock is locked before the while loop and also
locked again at the end of the while loop; it appears that the
lock at the end of the while loop is a double lock that should
be removed.  CoverityScan picked this up with the introduction
of the referenced commit inthe Fixes tag, however, it may have
existed before this.  I've not been able to test this, but it
does look incorrect to me.

Detected by CoverityScan, CID#1268846 ("Double lock")

Fixes: 827ed2b06b05 ("drm/ttm: use try_lock in ttm_bo_delayed_delete again")
Signed-off-by: Colin Ian King <colin.king@xxxxxxxxxxxxx>
---
  drivers/gpu/drm/ttm/ttm_bo.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 60bb5c12b568..fb8d13a4bc94 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -595,7 +595,6 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all)
  		}
kref_put(&bo->list_kref, ttm_bo_release_list);
-		spin_lock(&glob->lru_lock);
  	}
  	list_splice_tail(&removed, &bdev->ddestroy);
  	empty = list_empty(&bdev->ddestroy);

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Development]     [Kernel Announce]     [Kernel Newbies]     [Linux Networking Development]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Device Mapper]

  Powered by Linux