Hello,
On Tue, Jan 23, 2024 at 02:26:21PM +0100, Christian Brauner wrote:
> Signed-off-by: Christian Brauner <[email protected]>
> ---
> drivers/md/dm.c | 23 +++++++++++++----------
> drivers/md/md.c | 12 ++++++------
> drivers/md/md.h | 2 +-
> include/linux/device-mapper.h | 2 +-
> 4 files changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 8dcabf84d866..87de5b5682ad 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
...
> @@ -775,7 +778,7 @@ static void close_table_device(struct table_device *td,
> struct mapped_device *md
> {
> if (md->disk->slave_dir)
> bd_unlink_disk_holder(td->dm_dev.bdev, md->disk);
> - bdev_release(td->dm_dev.bdev_handle);
> + fput(td->dm_dev.bdev_file);
The above change caused regression on 'dmsetup remove_all'.
blkdev_release() is delayed because of fput(), so dm_lock_for_deletion
returns -EBUSY, then this dm disk is skipped in remove_all().
Force to mark DMF_DEFERRED_REMOVE might solve it, but need our device
mapper guys to check if it is safe.
Or other better solution?
thanks,
Ming
