linux-kernel - Re: deadlock in "modprobe -r ohci1394" shortly after "modprobe ohci1394"

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: <Pine.LNX.4.44L0.0611201942270.30952-100000@netrider.rowland.org>
Date:	Mon, 20 Nov 2006 19:49:23 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	linux1394-devel@...ts.sourceforge.net,
	Greg Kroah-Hartman <gregkh@...e.de>,
	<linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dtor@...ightbb.com>
Subject: Re: deadlock in "modprobe -r ohci1394" shortly after "modprobe
 ohci1394"

On Tue, 21 Nov 2006, Stefan Richter wrote:

> On 20 Nov, Alan Stern wrote:
> >> > Is the problem caused by the fact that some of these struct device's 
> >> > aren't bound to a driver?  Remember, bus_rescan_devices() will skip over 
> >> > anything that already has a driver.  Could you solve your problem by 
> >> > adding a do_nothing driver that would bind to these otherwise unused 
> >> > devices?
> 
> There are three minor problems with this approach:
>  - some ballast in system memory for the dummy driver struct
>  - the dummy driver is visible in sysfs
>  - the (root) user can unbind the driver which will recreate the
>    preconditions for the deadlock

I agree with all these objections.

The real issue here is the way ieee1394 sets up children of devices with
no driver.  On the face of it that is quite illogical: If a device has no
driver, then who can interrogate it to find out about its children?

USB faces a similar situation.  In a USB device, all the real work is 
actually done by "interfaces".  So we set up a device structure for the 
USB device itself, plus device structures for each of its interfaces.  The 
parent structure is bound to a (more or less) dummy driver, which insures 
that the child structures are deleted whenever it gets unbound.

Still, maybe some compromise can be reached.  Perhaps Dmitry's idea, or 
something like it, can be adopted.

Alan Stern

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