Do not decode DM flags for device removal

Do not decode DM flags for device removal

[Zdenek Kabelac]

A non-text attachment was scrubbed...
Name: udev_rules.patch
Type: text/x-patch
Size: 1848 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20110722/65f3a522/attachment.bin>

Do not decode DM flags for device removal

[Peter Rajnoha]

> diff --git a/udev/10-dm.rules.in b/udev/10-dm.rules.in
> index 606a13d..9e8ad0f 100644
> --- a/udev/10-dm.rules.in
> +++ b/udev/10-dm.rules.in
> @@ -24,12 +24,6 @@ ENV{DM_SBIN_PATH}="/sbin"
>  TEST!="$env{DM_SBIN_PATH}/dmsetup", ENV{DM_SBIN_PATH}="/usr/sbin"
>  TEST!="$env{DM_SBIN_PATH}/dmsetup", GOTO="dm_end"
>  
> -# Decode udev control flags and set environment variables appropriately.
> -# These flags are encoded in DM_COOKIE variable that was introduced in
> -# kernel version 2.6.31. Therefore, we can use this feature with
> -# kernels >= 2.6.31 only.
> -ENV{DM_COOKIE}=="?*", IMPORT{program}="$env{DM_SBIN_PATH}/dmsetup udevflags $env{DM_COOKIE}"
> -
>  # Device created, major and minor number assigned - "add" event generated.
>  # Table loaded - no event generated.
>  # Device resumed (or renamed) - "change" event generated.
> @@ -42,6 +36,12 @@ ENV{DM_COOKIE}=="?*", IMPORT{program}="$env{DM_SBIN_PATH}/dmsetup udevflags $env
>  # is not recommended.
>  ACTION!="add|change", GOTO="dm_end"
>  
> +# Decode udev control flags and set environment variables appropriately.
> +# These flags are encoded in DM_COOKIE variable that was introduced in
> +# kernel version 2.6.31. Therefore, we can use this feature with
> +# kernels >= 2.6.31 only.
> +ENV{DM_COOKIE}=="?*", IMPORT{program}="$env{DM_SBIN_PATH}/dmsetup udevflags $env{DM_COOKIE}"
> +
>  # Rule out easy-to-detect inappropriate events first.
>  ENV{DISK_RO}=="1", GOTO="dm_disable"

Well, for now, this is OK since nobody does any particular action on REMOVE
uevent, neither do we. So we don't actually need to decode any flags, that's
true. But what if someone adds a hook in the future? We also need to consider
any subsystem that makes use of libdevmapper.

So I'd say fine for now, but once there's a hook on REMOVE event anywhere,
expecting the flags to be decoded, we need to take care of proper dependencies
(among foreign packages vs. libdevmapper) if we revert this change back then.

Peter

Do not decode DM flags for device removal

[Peter Rajnoha]

On 07/25/2011 01:09 PM +0100, Peter Rajnoha wrote:
> So I'd say fine for now, but once there's a hook on REMOVE event anywhere,
> expecting the flags to be decoded, we need to take care of proper dependencies
> (among foreign packages vs. libdevmapper) if we revert this change back then.
> 

...though the only use I can imagine is that some libudev listener has
registered the device internally and then it needs to unregister it on
REMOVE. There's no point in running any scan from within udev rules on
that event since the device is already gone.

So doing some action on REMOVE event is possible and allowed, but its
use in the future is quite negligible and less probable...

Peter