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]

Date:	Thu, 25 Sep 2008 07:08:20 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Kay Sievers <kay.sievers@...y.org>
CC:	linux-kernel@...r.kernel.org, linux-hotplug@...r.kernel.org
Subject: Re: Differend udev names with different kernels

Kay Sievers wrote:
> 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.

Then this is a regression of the fastboot patch or whatever.

I will watch what will happen in 2.6.28-rc.

>> 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.

They currently work.  I never heard of them not working.

Even if there were already problems now, then the necessary course of 
action would be to fix them instead of dropping them.

Or fix the fine SCSI stack already to properly export target identifiers 
and LU identifiers.  (Not going to happen because the SCSI folks just 
don't get any midlayer stuff of that sort done, ever.)


> Or we can provide it as an additional link
> instead of making it skip the scsi-* link creation.

The scsi-* link may not be unique because it may be based on unsuitable 
information generated by the SBP-2 bridge device's firmware.


> 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?

I will look into it.
-- 
Stefan Richter
-=====-==--- =--= ==--=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/