linux-kernel - Re: [Patch 3/3] Driver core: Per-subsystem multithreaded probing.

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:	Mon, 16 Oct 2006 10:59:28 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
cc:	Duncan Sands <duncan.sands@...h.u-psud.fr>,
	Greg K-H <greg@...ah.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Patch 3/3] Driver core: Per-subsystem multithreaded probing.

On Mon, 16 Oct 2006, Cornelia Huck wrote:

> On Mon, 16 Oct 2006 11:13:30 +0200,
> Duncan Sands <duncan.sands@...h.u-psud.fr> wrote:
> 
> > There may have been a similar problem with
> > USB locking, since there too probe was expecting a lock to be held that might
> > not be held when called from the kthread:
> > 
> > 	 * This function must be called with @dev->sem held.  When called for a
> > 	 * USB interface, @dev->parent->sem must be held as well.
> > 	 */
> > 	int driver_probe_device(struct device_driver * drv, struct device * dev)
> 
> But as we don't know we're probing an usb interface, we have no chance
> of ensuring that dev->parent->sem is taken in the multithreaded case
> (meaning we couldn't do multithreaded probe for usb).

That's not quite true.  You could acquire dev->parent->sem always, just to
be certain.  However USB shouldn't use this form of multithreaded probing
in any case; it should instead use multiple threads for khubd.

> (Any idea why the
> parent's sem must be taken for usb interfaces?)

It's a peculiarity of the way USB works that some commands (Set
Configuration and port reset) affect the entire device, even though they
may be needed only by a driver for a single interface.  Some interface
drivers do need to issue these commands when they are probed.  The only
safe way to do it is to insure that their probe routines are called with
both the device and the interface semaphores held.

> > Also, what about device removal racing with probe?  Is it possible for someone to
> > attempt to remove a device in the gap between the call to device_attach and the
> > kthread actually running and doing the probe?  That would result in remove and
> > probe being called in the wrong order...
> 
> ->probe won't be called if the device is already being removed,

Because driver_probe_device() checks device_is_registered(dev) before 
doing anything else.

>  but
> that still results in bus->remove being called without a prior ->probe
> (but not drv->probe since dev->driver is not set at that time).

How so?  We shouldn't call bus->remove if a driver isn't bound.

Some other things were left out of the patch.  Since we can no longer know 
whether any drivers will get bound at all, device_attach() should now 
return void.  This means that bus_attach_device() can be simplified and 
should also return void.

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/