HAL and LUKS II: revenge of cryptsetup

[Dan Nicholson]

On Mon, Apr 21, 2008 at 7:48 AM, Sam Morris <sam at robots.org.uk> wrote:
> On Mon, 2008-04-21 at 10:36 -0400, David Zeuthen wrote:
>  > On Sun, 2008-04-20 at 16:32 +0000, Sam Morris wrote:
>  > > Next I did it the brute-force way: list the contents of /dev/mapper, do a
>  > > stat on each block device, look at st_rdev and compare it to the device
>  > > number of the event; if they match then look at the name. This doesn't
>  > > work either though... the 'temporary-cryptsetup-*' block device does not
>  > > appear in /dev/mapper by the time HAL has a change to read the directory.
>  > > Probably because cryptsetup removes the mapping too quickly.
>  > >
>  > > Any other ideas?
>  >
>  > The fundamental problem is that device-mapper creates it's own device
>  > nodes in /dev and that's why it's indeed racy. Instead it should rely on
>  > udev doing this (udev is supposed to manage /dev) and, FWIW, it's a
>  > known problem and have been discussed by myself, Alasdair and Kay on
>  > more than one occasion. For some reason I'm not seeing these races on
>  > Fedora so it "works" fine here (but probably not under load).
>
>  This seems to be what Ubuntu have done. I guess they have patched
>  libdevmapper not to creat the device nodes itself.

I haven't looked at this in any detail, but I think on suse (where Kay
Sievers maintains the udev package), they use these rules for
device-mapper:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=etc/udev/suse/64-device-mapper.rules;hb=HEAD

It seems like that's calling out to dmsetup to create the nodes and
integrating that information back into udev.

--
Dan