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, 23 Jan 2012 11:14:58 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Simon Glass <sjg@...omium.org>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	<linux-usb@...r.kernel.org>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
Subject: Re: [PATCH] usb: Use a workqueue in usb_add_hcd() to reduce boot
 time

On Fri, 20 Jan 2012, Simon Glass wrote:

> First, backing up a bit, there are at least two ways to solve this.
> One is to have the drivers only call usb_add_hcd() from a work queue
> or similar - i.e. not as part of their initcall execution. The other
> is what I have done here.
> 
> Before I go much further I would like to know which is
> best/preferable. Because in answer to your questions I'm not sure
> drivers have a way of dealing with failure of delayed init. It would
> need notification back to the driver at least.

I thought about this a little more.  Maybe it's okay not to unbind the 
driver when the async initialization fails.  After all, it's not like 
any other driver is going to want to manage that hardware.

But that still leaves problems.  Unregistration should work properly
even when async init fails.  The easiest solution seems to be to clear
hcd->self.root_hub whenever async initialization fails, and then in
usb_remove_hcd, return immediately if hcd->self.root_hub isn't set.  
Doing things this way, you avoid the need to modify all those
controller drivers.

That's not all.  You have a race between unbinding and async
initialization.  Probably you will need to make the work routine lock
the hcd->self.controller device, for mutual exclusion with unbinding.  
In addition, usb_remove_hcd should try to cancel the work routine, in
case it hasn't run yet.  And finally, for the case where both things
end up running concurrently, the work routine should check whether
unbinding has already started and fail immediately if it has.

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