linux-kernel - Re: [PATCH RFC] USB: Add HCD fastboot

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: <489A0467.1060607@simon.arlott.org.uk>
Date:	Wed, 06 Aug 2008 21:07:03 +0100
From:	Simon Arlott <simon@...e.lp0.eu>
To:	Alan Stern <stern@...land.harvard.edu>
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>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [PATCH RFC] USB: Add HCD fastboot

On 06/08/08 20:49, Alan Stern wrote:
> On Wed, 6 Aug 2008, Simon Arlott wrote:
> 
>> > Wouldn't it be much simpler, and less objectionable, to do what I
>> > suggested earlier?  That is, add a 5-second delay at the start of
>> > hub_thread() in drivers/usb/core/hub.c.  No messing with Makefiles, no
>> > changes to the initcall scheduling.
>> 
>> Aside from 5 seconds being too long, and anything less being a race between 
>> hub_thread() and driver initcalls, it doesn't improve anything because it'll 
>> still have to wait for the devices to finish initialising in userspace instead.
> 
> Why is 5 seconds too long?  Too long for what?
> 
> What you're doing is already a race between hub_thread() and driver 
> initcalls.  My suggestion is no worse.

No, by adding a 5 second delay you're intending for the device driver initcalls 
to complete within that 5 seconds. If they take too long then the last one 
blocks everything (I realise that's ridiculous, these initcalls take <1ms when 
there are no devices yet). The best way to do is to make the driver initcalls 
before the host ones, like you suggested.

> "it'll still have to wait..."  If by "it" you mean the initcall
> thread, you're wrong.  If by "it" you mean the user, you still aren't
> necessarily correct; the user can do plenty of other things while
> waiting for USB devices to initialize.

Assuming userspace doesn't wait for all devices to settle and appear in /dev etc. 
before continuing.

> I suppose you could make the hub_thread delay time a module parameter 
> for usbcore, defaulting to 0.  Then it could be set by just the people 
> who want to use it -- many (most?) people keep their drivers in 
> modules, and it wouldn't do them any good.

It really needs to have hcd initcalls done very early so that device init 
has the rest of the (kernel and userspace) boot process to complete in the 
background. This is negated by having device drivers initialised immediately 
afterwards. Re-ordering initcalls and doing more of the init process 
asynchronously is likely to expose bugs and cause inconsistent device order 
on some systems, so if the makefile mess could be reduced then it can be a 
Kconfig option.

How many people have *all* their USB components (hcd, drivers) as modules?
What do they do with their USB keyboards in the period between init and module 
load? If even one device driver and the hcd is compiled in, they'd need to 
wait for every USB device to finish init before the usbhid probe could complete.

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