diff options
author | Ming Lei <ming.lei@redhat.com> | 2024-04-16 03:56:33 +0300 |
---|---|---|
committer | Mike Snitzer <snitzer@kernel.org> | 2024-04-16 18:32:07 +0300 |
commit | 48ef0ba12e6b77a1ce5d09c580c38855b090ae7c (patch) | |
tree | ecfdef82e52f49202ae28fd6e34d980faa2acd84 /drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | |
parent | f141dde5dc51ecab18e8b12b76eb416cda0d6798 (diff) | |
download | linux-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