linux-kernel - Re: [patch 5/3] fastboot: sync the async execution before late

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.0807311510220.5019-100000@iolanthe.rowland.org>
Date:	Thu, 31 Jul 2008 15:16:35 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Simon Arlott <simon@...e.lp0.eu>
cc:	Rene Herman <rene.herman@...access.nl>,
	Arjan van de Ven <arjan@...radead.org>,
	<linux-kernel@...r.kernel.org>, <mingo@...e.hu>,
	Daniel Walker <dwalker@...sta.com>,
	USB list <linux-usb@...r.kernel.org>
Subject: Re: [patch 5/3] fastboot: sync the async execution before     
 late_initcall and move level 6s (sync) first

On Thu, 31 Jul 2008, Simon Arlott wrote:

> > If it were a module then it would block in a separate thread and 
> > wouldn't hold up the main init process.
> 
> Right, but I want to compile all of this into the kernel.

Okay, that explains things.  But this means that changes which are 
helpful on your system might not be so helpful (or might even be 
detrimental) on other people's systems.

> > It's not entirely clear why usblp is blocking at all.  Probably because
> > it is waiting on the device semaphores for devices that are currently
> > being probed -- the driver core won't allow two threads to probe the
> > same device concurrently.
> 
> Ok - so there could be some big improvements to be had by making the hcd 
> init happen as early as possible and the device initcalls later?

Maybe.  Perhaps a better approach would be to make the device driver 
initcalls before there are any devices for their probe routines to 
block on.

> > Driver probing is always going to be a bottleneck, even for
> > non-matching device/driver pairs.  That's because the driver core
> > acquires the device semaphore even before calling the bus's match
> > routine.  When a new driver is registered, the driver core just goes
> > down the list of all devices registered on the bus, locking each one in
> > turn and trying to match & probe it.
> 
> So could HCD init be moved higher in the initcall order so that the devices 
> have been initialised enough by khubd that device driver initcalls take 
> much less time?
> 
> I'm not really sure how to do that, except by doing usb/core/ usb/host/ 
> and then usb/class/ usb/storage/ etc....

Try doing this instead: Put a 5-second delay at the start of 
hub_thread().  That will give the in-kernel device drivers time to 
initialize before any USB devices -- other than root hubs -- are 
discovered.  That should speed up the init timings.

For everyone else, it will slow down USB device discovery by 5 seconds.  
I don't know how important that is, considering how much other stuff is 
going on at boot time.  You may find that 5 seconds is more than you 
need; perhaps 1 second will be enough.

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/