linux-kernel - Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove

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: <20061124084114.GE14340@kroah.com>
Date:	Fri, 24 Nov 2006 00:41:14 -0800
From:	Greg KH <greg@...ah.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Andrew Morton <akpm@...l.org>, Mattia Dongili <malattia@...ux.it>,
	linux1394-devel@...ts.sourceforge.net, bcollins@...ian.org,
	linux-kernel@...r.kernel.org
Subject: Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in	class_device_remove_attrs during nodemgr_remove_host)]

On Sun, Nov 19, 2006 at 10:01:06PM +0100, Stefan Richter wrote:
> Andrew Morton wrote:
> > On Sun, 19 Nov 2006 18:13:45 +0100
> > Stefan Richter <stefanr@...6.in-berlin.de> wrote:
> >> Looks very much like eth1394's sysfs interface is getting
> >> in the way. And since it is entirely handled by the ieee1394 core, it
> >> means ieee1394 needs the class_dev to dev treatment. I think it's OK if
> >> we just wait for Greg to finish his preliminary patch. Until then,
> >> CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks
> >> eth1394 broken or removes gregkh-driver-network-device.patch...)
> > 
> > Do we know what's actually wrong, and what needs to be done about it?
> 
> I for one don't know what's needed precisely. But at the moment I
> actually don't want to spend any more time on this because:
>  - It happens only if ohci1394 is unloaded while eth1394 is loaded.
>    (That's not an unusual condition though.)

Yes, I can trigger this quite easily here now.

>  - It happens only in -mm, and only because -mm contains the work-in-
>    progress patches for class_device -> device transition.
> I expect it to go away automatically once Greg is done with the
> transition. It seems Greg is the one to do it :-), at least I'm not
> available right now to lend a hand. There are older ieee1394 bugs in
> mainline with bigger practical impact for me to work on. If there are
> still issues once ieee1394 was converted away from class_device, I'm OK
> with revisiting it.

I'll hold off on submitting the network change to mainline until I fix
this problem, so it might be a while...

thanks for narrowing it down for me.

greg k-h
-
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/