Wrong symlink handling on rule changes

Wrong symlink handling on rule changes

[Matthias Schwarzott]

Hi there!
Playing around with rules I stepped over a strange thing.

I played with device-mapper rules, but the bug is about general symlink 
handling.

1. My rules did set this:
NAME="dm-0", SYMLINK="mapper/main-slash"
That results in /dev/dm-0 being a device-node and /dev/mapper/main-slash is a 
symlink to it.

2. Swapping NAME and SYMLINK
NAME="mapper/main-slash", SYMLINK="dm-0"
and running udevtrigger changes dm-0 to be a symlink to correct target.
BUT: It changes mapper/main-slash to be a symlink to itself.

Calling udevtrigger a second time will correct symlink.

Matthias
-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Wrong symlink handling on rule changes

[Alexander E. Patrakov]

Matthias Schwarzott wrote:
> Hi there!
> Playing around with rules I stepped over a strange thing.
>
> I played with device-mapper rules, but the bug is about general symlink 
> handling.
>
> 1. My rules did set this:
> NAME="dm-0", SYMLINK="mapper/main-slash"
> That results in /dev/dm-0 being a device-node and /dev/mapper/main-slash is a 
> symlink to it.
>
> 2. Swapping NAME and SYMLINK
> NAME="mapper/main-slash", SYMLINK="dm-0"
> and running udevtrigger changes dm-0 to be a symlink to correct target.
> BUT: It changes mapper/main-slash to be a symlink to itself.
>
> Calling udevtrigger a second time will correct symlink.
>   

Is this reproducible with non-device-mapper devices? I think (but I am
not sure) that the device-mapper library can poke into /dev by itself,
and thus calling dmsetup from the persistent storage rules may interfere
with normal udev operation here.

-- 
Alexander E. Patrakov


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Wrong symlink handling on rule changes

[Matthias Schwarzott]

On Donnerstag, 20. September 2007, Alexander E. Patrakov wrote:
> Matthias Schwarzott wrote:
> > Hi there!
> > Playing around with rules I stepped over a strange thing.
> >
> > I played with device-mapper rules, but the bug is about general symlink
> > handling.
> >
> > 1. My rules did set this:
> > NAME="dm-0", SYMLINK="mapper/main-slash"
> > That results in /dev/dm-0 being a device-node and /dev/mapper/main-slash
> > is a symlink to it.
> >
> > 2. Swapping NAME and SYMLINK
> > NAME="mapper/main-slash", SYMLINK="dm-0"
> > and running udevtrigger changes dm-0 to be a symlink to correct target.
> > BUT: It changes mapper/main-slash to be a symlink to itself.
> >
> > Calling udevtrigger a second time will correct symlink.
>
> Is this reproducible with non-device-mapper devices? I think (but I am
> not sure) that the device-mapper library can poke into /dev by itself,
> and thus calling dmsetup from the persistent storage rules may interfere
> with normal udev operation here.

Yes I can reproduce it with other devices.

Adding this rule:
KERNEL="sda", NAME="sda", SYMLINK="try1"

# udevtrigger
# ls -l /dev/sda /dev/try1
brw-r----- 1 root disk 8, 0 12. Sep 09:47 /dev/sda
lrwxrwxrwx 1 root root    3 20. Sep 17:31 /dev/try1 -> sda

Change rule to:
KERNEL="sda", SYMLINK+="sda", NAME="try1"

# udevtrigger
# ls -l /dev/sda /dev/try1
lrwxrwxrwx 1 root root 4 20. Sep 17:33 /dev/sda -> try1
lrwxrwxrwx 1 root root 4 20. Sep 17:33 /dev/try1 -> try1


# udevtrigger
# ls -l /dev/sda /dev/try1
lrwxrwxrwx 1 root root    4 20. Sep 17:33 /dev/sda -> try1
brw-r----- 1 root disk 8, 0 20. Sep 17:34 /dev/try1


Matthias

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Wrong symlink handling on rule changes

[Kay Sievers]

On 9/20/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> Playing around with rules I stepped over a strange thing.
>
> I played with device-mapper rules, but the bug is about general symlink
> handling.
>
> 1. My rules did set this:
> NAME="dm-0", SYMLINK="mapper/main-slash"
> That results in /dev/dm-0 being a device-node and /dev/mapper/main-slash is a
> symlink to it.
>
> 2. Swapping NAME and SYMLINK
> NAME="mapper/main-slash", SYMLINK="dm-0"
> and running udevtrigger changes dm-0 to be a symlink to correct target.
> BUT: It changes mapper/main-slash to be a symlink to itself.
>
> Calling udevtrigger a second time will correct symlink.

Might be fixed by this:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h%c208d659cf0f8bc887a1f7c62e9d2e0c546aec

I general, it's a bad idea to mess around with device nodes created by
other tools. Libdevmapper needs proper udev/kernel event integration
to allow this without doing unpredictable things.

Kay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Wrong symlink handling on rule changes

[Matthias Schwarzott]

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

On Donnerstag, 20. September 2007, Kay Sievers wrote:
> On 9/20/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> > Playing around with rules I stepped over a strange thing.
> >
> > I played with device-mapper rules, but the bug is about general symlink
> > handling.
> >
> > 1. My rules did set this:
> > NAME="dm-0", SYMLINK="mapper/main-slash"
> > That results in /dev/dm-0 being a device-node and /dev/mapper/main-slash
> > is a symlink to it.
> >
> > 2. Swapping NAME and SYMLINK
> > NAME="mapper/main-slash", SYMLINK="dm-0"
> > and running udevtrigger changes dm-0 to be a symlink to correct target.
> > BUT: It changes mapper/main-slash to be a symlink to itself.
> >
> > Calling udevtrigger a second time will correct symlink.
>
> Might be fixed by this:
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=25c208d659cf
>0f8bc887a1f7c62e9d2e0c546aec
>
> I general, it's a bad idea to mess around with device nodes created by
> other tools. Libdevmapper needs proper udev/kernel event integration
> to allow this without doing unpredictable things.
>
I know, but this was just an example. See my other example using sda and a 
symlink on it.

Even updating to latest git (that does contain patch above) does not help in 
this case.

Part of udevtest output (instead of udevtrigger call after rule change):

# grep try1 /tmp/udevtest-sda.txt
udev_rules_get_name: rule applied, 'sda' becomes 'try1'
udev_node_add: creating device node '/dev/try1', major=8, minor=0, mode=0640, 
uid=0, gid=6
update_link: 'sda' with target 'try1' has the highest priority 0, create it
update_link: 'disk/by-id/scsi-SATA_SAMSUNG_XXX' with target 'try1' has the 
highest priority 0, create it
update_link: 'disk/by-id/ata-SAMSUNG_XXX' with target 'try1' has the highest 
priority 0, create it
update_link: 'disk/by-path/pci-0000:00:0f.0-scsi-0:0:0:0' with target 'try1' 
has the highest priority 0, create it
udev_node_update_symlinks: update old symlink 'try1' no longer belonging 
to '/block/sda'
udev_db_get_devices_by_name: found index directory '/dev/.udev/names/try1'
update_link: found 1 devices with name 'try1'
update_link: found '/block/sda' for 'try1'
update_link: 'try1' with target 'try1' has the highest priority 0, create it
update_link: 'sda' with target 'try1' has the highest priority 0, create it



See the line that tells that try1 symlink has highest priority so create it.

Matthias

-- 
Matthias Schwarzott (zzam)

[-- Attachment #2: udevtest-sda.txt --]
[-- Type: text/plain, Size: 4618 bytes --]

This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

main: looking at device '/block/sda' from subsystem 'block'
udev_rules_get_name: add symlink 'sda'
udev_rules_get_name: rule applied, 'sda' becomes 'try1'
match_rule: set ENV 'DEVTYPE=disk'
run_program: 'usb_id --export /block/sda'
run_program: '/lib/udev/usb_id' returned with status 1
run_program: 'scsi_id --export --whitelisted --fallback-to-sysfs -s /block/sda -d /dev/.tmp-8-0'
run_program: '/lib/udev/scsi_id' (stdout) 'ID_VENDOR=ATA'
run_program: '/lib/udev/scsi_id' (stdout) 'ID_MODEL=SAMSUNG_XXX'
run_program: '/lib/udev/scsi_id' (stdout) 'ID_REVISION=ZZ10'
run_program: '/lib/udev/scsi_id' (stdout) 'ID_SERIAL=XXX'
run_program: '/lib/udev/scsi_id' (stdout) 'ID_SERIAL_SHORT=XXX'
run_program: '/lib/udev/scsi_id' (stdout) 'ID_TYPE=disk'
run_program: '/lib/udev/scsi_id' (stdout) 'ID_BUS=scsi'
run_program: '/lib/udev/scsi_id' returned with status 0
udev_rules_get_name: add symlink 'disk/by-id/scsi-SATA_SAMSUNG_XXX'
run_program: 'ata_id /dev/.tmp-8-0'
run_program: '/lib/udev/ata_id' returned with status 0
match_rule: set ENV 'ID_ATA_COMPAT=SAMSUNG_XXX'
udev_rules_get_name: add symlink 'disk/by-id/ata-SAMSUNG_XXX'
run_program: 'path_id /block/sda'
run_program: '/lib/udev/path_id' (stdout) 'ID_PATH=pci-0000:00:0f.0-scsi-0:0:0:0'
run_program: '/lib/udev/path_id' returned with status 0
udev_rules_get_name: add symlink 'disk/by-path/pci-0000:00:0f.0-scsi-0:0:0:0'
run_program: 'edd_id --export /dev/.tmp-8-0'
run_program: '/lib/udev/edd_id' (stderr) 'no kernel EDD support'
run_program: '/lib/udev/edd_id' returned with status 2
udev_device_event: device '/block/sda' already in database, cleanup
udev_node_add: creating device node '/dev/try1', major=8, minor=0, mode=0640, uid=0, gid=6
udev_node_update_symlinks: update symlink 'sda' of '/block/sda'
udev_db_get_devices_by_name: found index directory '/dev/.udev/names/sda'
update_link: found 1 devices with name 'sda'
update_link: found '/block/sda' for 'sda'
update_link: compare (our own) priority of '/block/sda' 0 >= 0
update_link: 'sda' with target 'try1' has the highest priority 0, create it
udev_node_update_symlinks: update symlink 'disk/by-id/scsi-SATA_SAMSUNG_XXX' of '/block/sda'
udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-id\x2fscsi-SATA_SAMSUNG_XXX'
update_link: found 1 devices with name 'disk/by-id/scsi-SATA_SAMSUNG_XXX'
update_link: found '/block/sda' for 'disk/by-id/scsi-SATA_SAMSUNG_XXX'
update_link: compare (our own) priority of '/block/sda' 0 >= 0
update_link: 'disk/by-id/scsi-SATA_SAMSUNG_XXX' with target 'try1' has the highest priority 0, create it
udev_node_update_symlinks: update symlink 'disk/by-id/ata-SAMSUNG_XXX' of '/block/sda'
udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-id\x2fata-SAMSUNG_XXX'
update_link: found 1 devices with name 'disk/by-id/ata-SAMSUNG_XXX'
update_link: found '/block/sda' for 'disk/by-id/ata-SAMSUNG_XXX'
update_link: compare (our own) priority of '/block/sda' 0 >= 0
update_link: 'disk/by-id/ata-SAMSUNG_XXX' with target 'try1' has the highest priority 0, create it
udev_node_update_symlinks: update symlink 'disk/by-path/pci-0000:00:0f.0-scsi-0:0:0:0' of '/block/sda'
udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-path\x2fpci-0000:00:0f.0-scsi-0:0:0:0'
update_link: found 1 devices with name 'disk/by-path/pci-0000:00:0f.0-scsi-0:0:0:0'
update_link: found '/block/sda' for 'disk/by-path/pci-0000:00:0f.0-scsi-0:0:0:0'
update_link: compare (our own) priority of '/block/sda' 0 >= 0
update_link: 'disk/by-path/pci-0000:00:0f.0-scsi-0:0:0:0' with target 'try1' has the highest priority 0, create it
udev_node_update_symlinks: update old symlink 'try1' no longer belonging to '/block/sda'
udev_db_get_devices_by_name: found index directory '/dev/.udev/names/try1'
update_link: found 1 devices with name 'try1'
update_link: found '/block/sda' for 'try1'
update_link: compare (our own) priority of '/block/sda' 0 >= 0
update_link: 'try1' with target 'try1' has the highest priority 0, create it
udev_db_get_devices_by_name: found index directory '/dev/.udev/names/sda'
update_link: found 1 devices with name 'sda'
update_link: found '/block/sda' for 'sda'
update_link: compare (our own) priority of '/block/sda' 0 >= 0
update_link: 'sda' with target 'try1' has the highest priority 0, create it
main: run: 'socket:/org/freedesktop/hal/udev_event'
main: run: 'socket:/org/kernel/udev/monitor'

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Wrong symlink handling on rule changes

[Kay Sievers]

On 9/20/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> On Donnerstag, 20. September 2007, Kay Sievers wrote:
> > On 9/20/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> > > Playing around with rules I stepped over a strange thing.
> > >
> > > I played with device-mapper rules, but the bug is about general symlink
> > > handling.
> > >
> > > 1. My rules did set this:
> > > NAME="dm-0", SYMLINK="mapper/main-slash"
> > > That results in /dev/dm-0 being a device-node and /dev/mapper/main-slash
> > > is a symlink to it.
> > >
> > > 2. Swapping NAME and SYMLINK
> > > NAME="mapper/main-slash", SYMLINK="dm-0"
> > > and running udevtrigger changes dm-0 to be a symlink to correct target.
> > > BUT: It changes mapper/main-slash to be a symlink to itself.
> > >
> > > Calling udevtrigger a second time will correct symlink.
> >
> > Might be fixed by this:
> > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h%c208d659cf
> >0f8bc887a1f7c62e9d2e0c546aec
> >
> > I general, it's a bad idea to mess around with device nodes created by
> > other tools. Libdevmapper needs proper udev/kernel event integration
> > to allow this without doing unpredictable things.
> >
> I know, but this was just an example. See my other example using sda and a
> symlink on it.
>
> Even updating to latest git (that does contain patch above) does not help in
> this case.
>
> Part of udevtest output (instead of udevtrigger call after rule change):
>
> # grep try1 /tmp/udevtest-sda.txt
> udev_rules_get_name: rule applied, 'sda' becomes 'try1'
> udev_node_add: creating device node '/dev/try1', major=8, minor=0, mode\x0640,
> uid=0, gid=6
> update_link: 'sda' with target 'try1' has the highest priority 0, create it
> update_link: 'disk/by-id/scsi-SATA_SAMSUNG_XXX' with target 'try1' has the
> highest priority 0, create it
> update_link: 'disk/by-id/ata-SAMSUNG_XXX' with target 'try1' has the highest
> priority 0, create it
> update_link: 'disk/by-path/pci-0000:00:0f.0-scsi-0:0:0:0' with target 'try1'
> has the highest priority 0, create it
> udev_node_update_symlinks: update old symlink 'try1' no longer belonging
> to '/block/sda'
> udev_db_get_devices_by_name: found index directory '/dev/.udev/names/try1'
> update_link: found 1 devices with name 'try1'
> update_link: found '/block/sda' for 'try1'
> update_link: 'try1' with target 'try1' has the highest priority 0, create it
> update_link: 'sda' with target 'try1' has the highest priority 0, create it
>
> See the line that tells that try1 symlink has highest priority so create it.

This happens once after changing conflicting rules with clashing names
and never again, right?
I guess the database content is out of sync with the current rules,
that's why that happens. I can add a check to prevent that.

Kay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Wrong symlink handling on rule changes

[Kay Sievers]

On 9/20/07, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On 9/20/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> > On Donnerstag, 20. September 2007, Kay Sievers wrote:
> > > On 9/20/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> > > > Playing around with rules I stepped over a strange thing.
> > > >
> > > > I played with device-mapper rules, but the bug is about general symlink
> > > > handling.
> > > >
> > > > 1. My rules did set this:
> > > > NAME="dm-0", SYMLINK="mapper/main-slash"
> > > > That results in /dev/dm-0 being a device-node and /dev/mapper/main-slash
> > > > is a symlink to it.
> > > >
> > > > 2. Swapping NAME and SYMLINK
> > > > NAME="mapper/main-slash", SYMLINK="dm-0"
> > > > and running udevtrigger changes dm-0 to be a symlink to correct target.
> > > > BUT: It changes mapper/main-slash to be a symlink to itself.
> > > >
> > > > Calling udevtrigger a second time will correct symlink.
> > >
> > > Might be fixed by this:
> > > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h%c208d659cf
> > >0f8bc887a1f7c62e9d2e0c546aec
> > >
> > > I general, it's a bad idea to mess around with device nodes created by
> > > other tools. Libdevmapper needs proper udev/kernel event integration
> > > to allow this without doing unpredictable things.
> > >
> > I know, but this was just an example. See my other example using sda and a
> > symlink on it.
> >
> > Even updating to latest git (that does contain patch above) does not help in
> > this case.
> >
> > Part of udevtest output (instead of udevtrigger call after rule change):
> >
> > # grep try1 /tmp/udevtest-sda.txt
> > udev_rules_get_name: rule applied, 'sda' becomes 'try1'
> > udev_node_add: creating device node '/dev/try1', major=8, minor=0, mode\x0640,
> > uid=0, gid=6
> > update_link: 'sda' with target 'try1' has the highest priority 0, create it
> > update_link: 'disk/by-id/scsi-SATA_SAMSUNG_XXX' with target 'try1' has the
> > highest priority 0, create it
> > update_link: 'disk/by-id/ata-SAMSUNG_XXX' with target 'try1' has the highest
> > priority 0, create it
> > update_link: 'disk/by-path/pci-0000:00:0f.0-scsi-0:0:0:0' with target 'try1'
> > has the highest priority 0, create it
> > udev_node_update_symlinks: update old symlink 'try1' no longer belonging
> > to '/block/sda'
> > udev_db_get_devices_by_name: found index directory '/dev/.udev/names/try1'
> > update_link: found 1 devices with name 'try1'
> > update_link: found '/block/sda' for 'try1'
> > update_link: 'try1' with target 'try1' has the highest priority 0, create it
> > update_link: 'sda' with target 'try1' has the highest priority 0, create it
> >
> > See the line that tells that try1 symlink has highest priority so create it.
>
> This happens once after changing conflicting rules with clashing names
> and never again, right?
> I guess the database content is out of sync with the current rules,
> that's why that happens. I can add a check to prevent that.

Does that prevent the broken link?
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h²d1ae727e78ac3e22caa11798360d87775095ff

Thanks,
Kay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Wrong symlink handling on rule changes

[Matthias Schwarzott]

On Donnerstag, 20. September 2007, Kay Sievers wrote:
> On 9/20/07, Kay Sievers <kay.sievers@vrfy.org> wrote:

> > This happens once after changing conflicting rules with clashing names
> > and never again, right?
> > I guess the database content is out of sync with the current rules,
> > that's why that happens. I can add a check to prevent that.
>
> Does that prevent the broken link?
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h²d1ae727e78
>ac3e22caa11798360d87775095ff
>
Yeah that patch works. Thanks.

Matthias


-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel