summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
diff options
context:
space:
mode:
authorMing Lei <ming.lei@redhat.com>2024-04-16 03:56:33 +0300
committerMike Snitzer <snitzer@kernel.org>2024-04-16 18:32:07 +0300
commit48ef0ba12e6b77a1ce5d09c580c38855b090ae7c (patch)
treeecfdef82e52f49202ae28fd6e34d980faa2acd84 /drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
parentf141dde5dc51ecab18e8b12b76eb416cda0d6798 (diff)
downloadlinux-48ef0ba12e6b77a1ce5d09c580c38855b090ae7c.tar.xz
dm: restore synchronous close of device mapper block device
'dmsetup remove' and 'dmsetup remove_all' require synchronous bdev release. Otherwise dm_lock_for_deletion() may return -EBUSY if the open count is > 0, because the open count is dropped in dm_blk_close() which occurs after fput() completes. So if dm_blk_close() is delayed because of asynchronous fput(), this device mapper device is skipped during remove, which is a regression. Fix the issue by using __fput_sync(). Also, DM device removal has long supported being made asynchronous by setting the DMF_DEFERRED_REMOVE flag on the DM device. So leverage using async fput() in close_table_device() if DMF_DEFERRED_REMOVE flag is set. Reported-by: Zhong Changhui <czhong@redhat.com> Fixes: a28d893eb327 ("md: port block device access to file") Suggested-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Ming Lei <ming.lei@redhat.com> [snitzer: editted commit header, use fput() if DMF_DEFERRED_REMOVE set] Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/amdgpu_object.c')
0 files changed, 0 insertions, 0 deletions