There may be a race window here: 1. all paths gone, causing map flushed both from multipathd and kernel 2. paths regenerated, causing multipathd creating the map again. 1 will generate a remove uevent which can be handled after 2, so we can disable queueing for the map created by 2 here temporarily and let the change uevent (generated by 2) calling uev_add_map->setup_multipath to set queueing again. This can prevent the deadlock in this race window. The possible deadlock is: all udevd workers hangs in devices because of queue_if_no_path, so no udevd workers can handle new event and since multipathd will remove the map, the checkerloop cannot check this map's retry tick timeout and cancel the io hang which makes the udevd worker hang forever. multipathd cannot receive any uevent from udevd because all udevd workers hang there so the map cannot be recreated again which makes a deadlock. Signed-off-by: Lixiaokeng@xxxxxxxxxx --- multipathd/main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/multipathd/main.c b/multipathd/main.c index baa18183..d7e20a10 100644 --- a/multipathd/main.c +++ b/multipathd/main.c @@ -798,6 +798,7 @@ uev_remove_map (struct uevent * uev, struct vectors * vecs) goto out; } + dm_queue_if_no_path(alias, 0); remove_map_and_stop_waiter(mpp, vecs); out: lock_cleanup_pop(vecs->lock); -- -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
