Subject: [RFC PATCH] cryptsetup: replace udevsettle calls with temporary device error remapping
Date: Thursday 4th September 2008 13:24:05 UTC (over 9 years ago)
Hi Clemens & all, recently was in cryptsetup introduced udevadm (udevsettle) call. That solved some problems, but introduced many others: - if cryptsetup is started through udev rules, it deadlocks (waiting for itself) and need full timeout to recover (180 or 30 seconds) - if udevd is not running yet (early installation, recovery, etc) it waits for this timeout too - it waits for other devices changes unnecessarily. why it should wait for all disc to settle? - using system() call in software like cryptsetup should be avoided IMHO the udev command introduction is the not good idea. I tried to install Fedora recently, using 3 encrypted logical volumes. Every volume, two udevsettle calls, 6 x 180 timeout. Unusable without manually kill the udevsettle process! What's the problem - udev triggers activation of temporary-cryptsetup-$PID device, keeping it open. So meaning of udevsettle is to ensure that all udev scanning is done and no process has this temporary device open. (So it is problem of wrong udev rules in the first case!) But we can use device mapper and remap open device, similar way how "dmsetup -f remove works" instead of waiting. See attached patch. Please could we submit it upstream? Better ideas welcome:) Patch description: - It adds force flag to device-mapper backend remove call. If force flag is specified, temporary mapped device is replaced by read only error segment (all IO will return -EIO now). It basically finish ongoing IO transaction and all following IOs should finish immediately with error. So the udev scanning should be finished very quickly now :-) Force flag must not be set for real mapping, if real (not temporary) mapped device is still open, there can be mounted fs or so - so it is correct to fail here. - After replacing with error device, It tries to remove temporary-device completely - RETRY_COUNT times. In the worst case it fails (someone still blocking temporary device), but underlying crypt device is now not used in mapping, so we can continue safely. (IOW: in the worst case it keeps temporary error mapped device in system. If this happens, the problem is for sure in some system cfg, nobody should try to open temporary cryptsetup devices. But it is not blocking cryptsetup from operation now. It is workaround till udev rules are fixed in all distros to not touch temporary cryptsetup devices...) - It removes udev calls completely. Not needed now. - It uses dm_task_update_nodes() instead of dm library reinitialization workaround. Patch is based on upstream SVN + my previous zero fd patch in ctrl+c handler. Milan -- [email protected] p.s. any feedback appreciated, I would like to submit this patch to Fedora cryptsetup ASAP...