If dm_hold_control_open() isn't set, when dm_lib_release() is called, it
will close the control fd. The control fd will get re-opened on the next
dm_task_run() call, but if there is a dm_task_run() call already
in progress in another thread, it can fail. Since many of the
device-mapper callouts happen with the vecs lock held, this wasn't too
noticeable, but there is code that calls dm_task_run() without the
vecs lock held, notably the dmevent waiter code.
Signed-off-by: Benjamin Marzinski <bmarz...@redhat.com>
---
libmultipath/devmapper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libmultipath/devmapper.c b/libmultipath/devmapper.c
index bed8ddc6..d96472fe 100644
--- a/libmultipath/devmapper.c
+++ b/libmultipath/devmapper.c
@@ -254,6 +254,7 @@ void libmp_dm_init(void)
memcpy(conf->version, version, sizeof(version));
put_multipath_config(conf);
dm_init(verbosity);
+ dm_hold_control_dev(1);
dm_udev_set_sync_support(libmp_dm_udev_sync);
}
--
2.17.2
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
