blob: 4098d042fd53b336ee85f3e2397c35808a33c6c7 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
Work around LVM/cryptsetup errors like:
semid 32768: semop failed for cookie 0xd4d41f4: incorrect semaphore state
Failed to set a proper state for notification semaphore identified by cookie value 223166964 (0xd4d41f4) to initialize waiting for incoming notifications.
and (when running "cryptsetup --debug"):
Uevent not generated! Calling udev_complete internally to avoid process lock-up.
Here for some reason libdm *thinks* that the uevent hasn't been
emitted, so it calls udev_complete. But the uevent actually *has*
been emitted, so udev calls ‘dmsetup udevcomplete’ as well, leading to
a race.
This is probably a reoccurence of the problem described here:
http://www.redhat.com/archives/dm-devel/2011-August/msg00075.html
http://www.redhat.com/archives/linux-lvm/2011-September/msg00023.html
which was fixed in the kernel, so it's not clear why it's surfacing
again. Maybe netlink_broadcast_filtered() has started returning some
other bogus error code.
diff -ru -x '*~' LVM2.2.02.98/libdm/ioctl/libdm-iface.c LVM2.2.02.98-new/libdm/ioctl/libdm-iface.c
--- LVM2.2.02.98/libdm/ioctl/libdm-iface.c 2012-10-15 10:24:58.000000000 -0400
+++ LVM2.2.02.98-new/libdm/ioctl/libdm-iface.c 2012-10-15 14:19:06.774363736 -0400
@@ -1754,9 +1754,12 @@
if (ioctl_with_uevent && dm_udev_get_sync_support() &&
!_check_uevent_generated(dmi)) {
+ log_debug("warning: Uevent might not be generated!");
+#if 0
log_debug("Uevent not generated! Calling udev_complete "
"internally to avoid process lock-up.");
_udev_complete(dmt);
+#endif
}
if (!_dm_ioctl_unmangle_names(dmt->type, dmi))
|