Re: [dm-crypt] 1.1.0rc2: device-mapper: remove ioctl failed: Device or resource busy

["Thomas Bächler" <thomas@archlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 6294 bytes --]

Peter Rajnoha schrieb:
> Well, we are in the process of the changeover now. As Milan says, what
> we're trying to do is to centralize the udev support for DM devices.
> There were (are?) bits of the rules touching dm devices all over the
> udev rule sets from other packages.

Is a public discussion happening somewhere? I'd like to follow it or 
even participate, as I will be the one who has to fix up this mess in 
the end for Arch.

>>> ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="dm-[0-9]*",
>>> PROGRAM="/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M
>>> -m %m", RESULT=="temporary-cryptsetup-*", OPTIONS="last_rule"
>>>
> 
> Yes, something is definitely touching it. We have OPTIONS+="last_rule" in
> lvm/dm upstream udev rules for temporary-cryptsetup devices now. But the
> thing is that using last_rule is also a source of the complaints and
> people just do not want to see this (for example, this was also the first
> thing that Debian lvm maintainer removed and diverted from the upstream).
> 
> Frankly, as for me, I would use last_rule here (as well as for hidden lvm
> devices and all devices that are temporary, hidden or special in any way
> so it has no meaning to process any other rules for them further). I asked
> Kay Sievers (from udev) what's his opinion about this and I got simple
> and straight answer from him:
> 
> "I can not think of any valid use of last_rule. Also, it will still
> send out the events to listeners, as this can never be suppressed.
> last_rule should probably just be removed, as is breaks all sorts of
> things and creates an inconsistent behavior."

If there is no mechanism to tell udev to ignore a certain device, 
shouldn't it be possible to tell the dm subsystem to not raise a uevent 
for a device? I imagine setting a "temporary" flag.

> I've posted patches on lvm-devel that introduce udev flags with which we
> can disable certain parts of the udev rules. Then these flags could be
> checked for and inappropriate parts of udev rules skipped (considering upstream):
> 
> DM_UDEV_FLAG_DISABLE_DISK_RULES - to disable 12-dm-disk.rules
> 
> DM_UDEV_FLAG_DISABLE_SUBSYSTEM_RULES - disable any subsystem rules, like 11-lvm.rules
>                                        for LVM... The same could be applied for any
>                                        other subsystem supplying its own rules.
> 
> These flags could be set directly in libdevmapper for each device being processed
> (but that's only for kernels >= 2.6.31, because we use cookie values to pass this
> information and they were introduced only in 2.6.31). Or we can set these flags
> directly in udev rules (like I'm proposing now on lvm-devel where I removed
> last_rule for temporary-cryptsetup and like and set these flags directly).

I don't get how this is better than last_rule, except it is more work 
and adds extra complexity. All I want is that temporary devices are 
being left alone completely.

Your quote from Kay Sievers also mentions events being sent to 
listeners, which can "never be suppressed" - the fact is that we 
want/need to suppress them - what you suggest doesn't change that.

Anyway, looking at the udev manpage, there seems to be a "ignore_device" 
option, is that better than last_rule? Shouldn't it fit our situation 
better? Or is it yet another option we shouldn't use?

> But such solution (I mean the one without last_rule) expects that everybody else
> will be playing device-mapper rules as well. It means always checking these
> flags and skip the rules if it is instructed to do so. This solution is much cleaner
> from udev perspective since it does not use that last_rule functionality...

Not only dm-specific rules but all rules everywhere need to be aware of 
this. There's also site/user-specific rules which could break and and 
and - as I said, extra complexity.

> I know, the solution with OPTIONS+="last_rule" would be much easier, since it
> ignores any rules further, but at least this way we can spot all the places where
> dm devices are touched by the rules and we can send a notice to those maintainers.
> Otherwise this would be hidden forever.

Good point - but I still think that telling udev to leave the device 
alone completely feels like the right thing to do.

>>> What is this remove error caused by, if not by some application being
>>> called from udev blocking access? Note that there are no
>>> temporary-cryptsetup-* volumes left after luksOpen.
>> No idea - but always I debubugged it, it was initiated from udev event
>> through udev rule.
> 
> ..hmm, this is bound to the actual ruleset that is used in each distro. Each
> one should be cleaned and any help is a welcome, really. Also, if you spot any
> strange behaviour related to DM devices and udev, just feel free to CC me.
> 
> Also, I would be very glad if all the rules in all distros would be in sync
> with upstream ones. If we could achieve that, it would be great, so we would
> have one base and we don't have to solve various problems over and over again.

We're trying to do that, but I think there are some legacies in our 
packages - device-mapper didn't have upstream udev rules in the past, so 
we added one to get the /dev/mapper/* devices created. That rule is 
still there, and probably nobody checked if upstream included something 
themselves.

> ..this is Arch Linux, right? I'll take a look...

Indeed.

Our udev rules are a big mess right now for various reasons I wanted to 
address soon. All I can say is that the only dm-specific rule is 
(included in the device-mapper package):

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="dm-[0-9]*", 
PROGRAM="/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M 
-m %m", NAME="mapper/%c", MODE="0600", SYMLINK+="disk/by-name/%c"

Then, the devicekit package also has some rules specific to dm, which I 
didn't look at yet (I guess they are just the upstream devicekit rules, 
we tend to not change them when possible).

The problematic rules are the ones that will just touch any block device 
- none of those has an explicit check to include or exclude dm-*. I 
think this should only be blkid, but I am not sure.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]