linux-kernel - Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class

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:	Sun, 13 May 2007 13:43:50 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Greg KH <greg@...ah.com>
CC:	linux-kernel@...r.kernel.org,
	linux1394-devel@...ts.sourceforge.net,
	Ismail D?nmez <ismail@...dus.org.tr>,
	Adrian Bunk <bunk@...sta.de>, Thomas Meyer <thomas@...3r.de>,
	Tobias Diedrich <ranma@...edrich.de>
Subject: Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394"
 after network class_device conversion

I wrote on 2007-03-21:
> On 20 Mar, Greg KH wrote:
>> On Tue, Mar 20, 2007 at 10:43:22PM +0100, Stefan Richter wrote:
>>> @@ -586,7 +586,10 @@ static void ether1394_add_host (struct h
>>>          }
>>>  
>>>  	SET_MODULE_OWNER(dev);
>>> +#if 0
>>> +	/* FIXME - Is this the correct parent device anyway? */
>>>  	SET_NETDEV_DEV(dev, &host->device);
>>> +#endif
>> That's interesting.  What does 'tree /sys/class/net/' look like with
>> this patch applied?  Does the eth1394 device now live off in
>> /sys/device/virtual?
> 
> Yes.
> 
> lrwxrwxrwx  1 root root 0 Mär 21 01:02 eth0 -> ../../devices/pci0000:00/0000:00:0b.0/eth0/
> lrwxrwxrwx  1 root root 0 Mär 21 01:02 eth1 -> ../../devices/virtual/net/eth1/
> lrwxrwxrwx  1 root root 0 Mär 21 01:02 lo -> ../../devices/virtual/net/lo/
> 
> (eth1 is IP over 1394 alias eth1394. eth0 is an actual ethernet
> interface.)
> 
> And eth1/device (ex -> ../../../devices/pci*___*/fw-host*) is now gone.
> Would anybody miss it?
> 
>> If so, I guess this is ok for now as we can wait for the rewrite of the
>> ieee1394 subsystem to get the linking done correctly :)
> 
> That's my hope too.

Alas there is some userspace breakage:
https://bugs.gentoo.org/show_bug.cgi?id=177199

| Ethernet over firewire devices (driver: eth1394) have - starting with
kernel
| 2.6.21 - no longer a proper parent-device/subsystem in sysfs.
|
| The code change resulting in this is:
[...]
| This missing parent-device breaks persistence-net, as that adds
DRIVERS=="?*"
| to the generated rules, but the driver-attribute resides in the
parent-device
| that no longer is available now.
|
| This leads to not matching the existing rule, but at every boot
running into
| the code to get a new number for the interface, and thus enlarging the
ruleset
| with one line at every boot.

I didn't notice this problem on my own Gentoo box here.  But then I
rarely reboot and don't automatically load eth1394 anymore since I
applied a post-2.6.21 patch which uncouples ieee1394 from eth1394.  I
still load it manually for frequent testing though.
-- 
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/