From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 20 Oct 2009 14:13:36 +0200 (CEST) MIME-version: 1.0 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KRT00HZNBAOT6C0@mta-2.ms.rz.RWTH-Aachen.de> for dm-crypt@saout.de; Tue, 20 Oct 2009 14:13:36 +0200 (CEST) Received: from [134.61.47.76] ([unknown] [134.61.47.76]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KRT00BVCBANW200@relay-auth-1.ms.rz.rwth-aachen.de> for dm-crypt@saout.de; Tue, 20 Oct 2009 14:13:36 +0200 (CEST) Message-id: <4ADDA96F.2080109@archlinux.org> Date: Tue, 20 Oct 2009 14:13:35 +0200 From: =?ISO-8859-15?Q?Thomas_B=E4chler?= References: <4ADD7639.6060904@archlinux.org> <4ADD7B1F.9060704@redhat.com> <4ADD9876.8000006@redhat.com> In-reply-to: <4ADD9876.8000006@redhat.com> Content-type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary=------------enig58082587534CC33785D9870C Subject: Re: [dm-crypt] 1.1.0rc2: device-mapper: remove ioctl failed: Device or resource busy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Rajnoha Cc: dm-crypt@saout.de, Milan Broz This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58082587534CC33785D9870C Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable 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=20 even participate, as I will be the one who has to fix up this mess in=20 the end for Arch. >>> ACTION=3D=3D"add|change", SUBSYSTEM=3D=3D"block", KERNEL=3D=3D"dm-[0-= 9]*", >>> PROGRAM=3D"/sbin/dmsetup info -c --noopencount --noheadings -o name -= j %M >>> -m %m", RESULT=3D=3D"temporary-cryptsetup-*", OPTIONS=3D"last_rule" >>> >=20 > Yes, something is definitely touching it. We have OPTIONS+=3D"last_rule= " in > lvm/dm upstream udev rules for temporary-cryptsetup devices now. But th= e > 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 fir= st > thing that Debian lvm maintainer removed and diverted from the upstream= ). >=20 > Frankly, as for me, I would use last_rule here (as well as for hidden l= vm > devices and all devices that are temporary, hidden or special in any wa= y > so it has no meaning to process any other rules for them further). I as= ked > Kay Sievers (from udev) what's his opinion about this and I got simple > and straight answer from him: >=20 > "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,=20 shouldn't it be possible to tell the dm subsystem to not raise a uevent=20 for a device? I imagine setting a "temporary" flag. > I've posted patches on lvm-devel that introduce udev flags with which w= e > can disable certain parts of the udev rules. Then these flags could be > checked for and inappropriate parts of udev rules skipped (considering = upstream): >=20 > DM_UDEV_FLAG_DISABLE_DISK_RULES - to disable 12-dm-disk.rules >=20 > DM_UDEV_FLAG_DISABLE_SUBSYSTEM_RULES - disable any subsystem rules, lik= e 11-lvm.rules > for LVM... The same could be app= lied for any > other subsystem supplying its ow= n rules. >=20 > These flags could be set directly in libdevmapper for each device being= processed > (but that's only for kernels >=3D 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 the= se flags > directly in udev rules (like I'm proposing now on lvm-devel where I rem= oved > last_rule for temporary-cryptsetup and like and set these flags directl= y). I don't get how this is better than last_rule, except it is more work=20 and adds extra complexity. All I want is that temporary devices are=20 being left alone completely. Your quote from Kay Sievers also mentions events being sent to=20 listeners, which can "never be suppressed" - the fact is that we=20 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=20 better? Or is it yet another option we shouldn't use? > But such solution (I mean the one without last_rule) expects that every= body else > will be playing device-mapper rules as well. It means always checking t= hese > 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 functionalit= y... Not only dm-specific rules but all rules everywhere need to be aware of=20 this. There's also site/user-specific rules which could break and and=20 and - as I said, extra complexity. > I know, the solution with OPTIONS+=3D"last_rule" would be much easier, = since it > ignores any rules further, but at least this way we can spot all the pl= aces where > dm devices are touched by the rules and we can send a notice to those m= aintainers. > Otherwise this would be hidden forever. Good point - but I still think that telling udev to leave the device=20 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. >=20 > ..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 s= pot any > strange behaviour related to DM devices and udev, just feel free to CC = me. >=20 > 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=20 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=20 still there, and probably nobody checked if upstream included something=20 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=20 address soon. All I can say is that the only dm-specific rule is=20 (included in the device-mapper package): ACTION=3D=3D"add|change", SUBSYSTEM=3D=3D"block", KERNEL=3D=3D"dm-[0-9]*"= ,=20 PROGRAM=3D"/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M= =20 -m %m", NAME=3D"mapper/%c", MODE=3D"0600", SYMLINK+=3D"disk/by-name/%c" Then, the devicekit package also has some rules specific to dm, which I=20 didn't look at yet (I guess they are just the upstream devicekit rules,=20 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=20 think this should only be blkid, but I am not sure. --------------enig58082587534CC33785D9870C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkrdqW8ACgkQEda5KzHP/VBx2gCgjzwYbLfCgrAcdBCfhzXaVckY E1gAoJFZyTQFjJPMyUu9MsQOFrFdvcQf =cDEP -----END PGP SIGNATURE----- --------------enig58082587534CC33785D9870C--