On recent kernels, calling drm_ht_remove triggers a might_sleep() warning
from within vfree(). So avoid calling it from atomic context. The use-cases
we fix here are both from destructors so there should be no concurrent
use of the hash tables.
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Brian Paul <bri...@vmware.com>
Reviewed-by: Sinclair Yeh <s...@vmware.com>
---
drivers/gpu/drm/ttm/ttm_object.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index d750140..26a7ad0 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -453,10 +453,10 @@ void ttm_object_file_release(struct ttm_object_file
**p_tfile)
ttm_ref_object_release(&ref->kref);
}
+ spin_unlock(&tfile->lock);
for (i = 0; i < TTM_REF_NUM; ++i)
drm_ht_remove(&tfile->ref_hash[i]);
- spin_unlock(&tfile->lock);
ttm_object_file_unref(&tfile);
}
EXPORT_SYMBOL(ttm_object_file_release);
@@ -533,9 +533,7 @@ void ttm_object_device_release(struct ttm_object_device
**p_tdev)
*p_tdev = NULL;
- spin_lock(&tdev->object_lock);
drm_ht_remove(&tdev->object_hash);
- spin_unlock(&tdev->object_lock);
kfree(tdev);
}
--
2.5.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
