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] [day] [month] [year] [list]
Date:	Tue, 17 Apr 2007 11:59:16 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Greg KH <greg@...ah.com>
cc:	Cornelia Huck <cornelia.huck@...ibm.com>,
	Tejun Heo <htejun@...il.com>,
	Markus Rechberger <markus.rechberger@....com>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] How should an exit routine wait for release()
 callbacks?

On Mon, 16 Apr 2007, Greg KH wrote:

> > > I've got a module which registers a struct device.  (It represents a
> > > virtual device, not a real one, but that doesn't matter.)
> 
> Wait, that's the issue right there.
> 
> Don't do that.
> 
> devices should be created by busses or the platform core, which owns the
> release function for them.  Individual drivers should not create
> devices.
> 
> Hm, but then, how would you ever unload a bus, as the same issue might
> be there too...
> 
> Any specific code in the kernel you can point to that has this issue
> today?

I first noticed it while working with dummy_hcd.  It creates a virtual 
host controller platform device and a virtual device controller platform 
device.  Its exit routine doesn't wait (and has no way to wait) for the 
release methods of those devices to finish executing.

But the same issue tends to pop up anywhere you have a "bridge" device --
one that connects two different kinds of bus.  For instance, a PC-card
essentially bridges a CardBus to whatever you can plug into that card.  
usb-storage essentially bridges a USB bus to a SCSI bus.  uhci-hcd
essentially bridges a PCI bus to a USB bus.

The problem itself isn't very noticeable.  Existing uses of
try_module_get() generally reduce it to an unlikely race, and the
uncoupling of sysfs from devices will make it even rarer.

But the problem still exists potentially.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ