nixpkgs/pkgs/os-specific/linux/lvm2/assume-uevent-generated.patch

40 lines
1.6 KiB
Diff
Raw Normal View History

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))