linux-kernel - Re: Differend udev names with different kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ae72650809242012r7d144a64l35777f2a7bacbaa0@mail.gmail.com>
Date:	Wed, 24 Sep 2008 20:12:09 -0700
From:	"Kay Sievers" <kay.sievers@...y.org>
To:	linux-kernel@...r.kernel.org, linux-hotplug@...r.kernel.org
Cc:	"Stefan Richter" <stefanr@...6.in-berlin.de>
Subject: Re: Differend udev names with different kernels

On Wed, Sep 24, 2008 at 13:01, Tino Keitel <tino.keitel@....de> wrote:
> what's the intention of /dev/disk/by-id/?
>
> My firewire hard disk seems to have different names with different
> kernels.
>
> With 2.6.26.3, it's name is
> /dev/disk/by-id/ieee1394-0030e001e0006585:00043c:0000.
>
> With someting after 2.6.27-rc7, merged with Arjan's fastboot branch,
> the disk has the same name.
>
> With 2.6.27-rc7, it is called
> /dev/disk/by-id/scsi-1WDC_WD10EACS-00D6B0_WD-WCAU41668315.

Seems, for some reason, the "ieee1394_id" attribute becomes readable
because of lucky timing, which wasn't the case before.

> One major config difference is that 2.6.26.3 has CONFIG_FIREWIRE and
> CONFIG_FIREWIRE_SBP2 set to "m", whereas the 2.6.27 kernels have set
> them to "y". But that doesn't explain the difference between both
> 2.6.27-rc kernels.

I guess, it's just a not-easy-to-reproduce timing issue with the sysfs
attribute.

> Shouldn't these names be somewhat constant? Otherwise they would be
> totally useless.

Yeah, sure they should not change like this.

We could just drop the ieee1394-* link creation entirely, if they
never worked as expected. Or we can provide it as an additional link
instead of making it skip the scsi-* link creation. Tino, care to try
if something like the attached works for your setup and creates at
least the scsi-links, and, if luckily timed, the ieee1394 links?

Stefan, ieee1394 hooks into scsi logic which, i guess, creates the
attribute _after_ event time, so udev will not see the attribute when
the device is announced. Any idea how to fix that?

Thanks,
Kay

View attachment "ieee1394-links-fix.patch" of type "text/x-patch" (1790 bytes)