linux-kernel - Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"

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:	Tue, 15 Jan 2013 16:25:54 -0800
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ming Lei <ming.lei@...onical.com>,
	Alex Riesen <raa.lkml@...il.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Jens Axboe <axboe@...nel.dk>,
	USB list <linux-usb@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: USB device cannot be reconnected and khubd "blocked for more
 than 120 seconds"

> For now, I'm gonna implement simple "I'm not gonna wait for myself"
> self-deadlock avoidance.  If this needs any more sophistication, I
> think we better reimplement it so that we can explicitly match up and
> track who's gonna wait for what instead of throwing everything into a
> single cookie space and then try to work back from there.

async fundamentally had the concept of a monotonic increasing number,
and that you could always wait for "everyone before me".
then people (like me) wanted exceptions to what "everyone" means ;-(
I'm ok with going back to a single space and simplify the world.

the case with (usb) module loading is "fun"...
people expect the device to be there (since frankly, it's hard to do otherwise)..
... but it's also really hard due to the nature of USB.. USB is async in nature,
even independent of the kernel async stuff.
Example: Load ehci.ko ... the actual use devices don't show up for some time.

the module wait case is tricky, and I wonder if there's deadlocks lurking even without async.
(btw there is a similar situation at the end of the normal kernel boot versus things like asynchronous
driver initializing... but we "skip" that in the case of an initrd is used to bypass a very similar deadlock.
this is even without "async" in use.. typical hard case is the PS/2 mouse probing)

at some point in the past we had the concept of "request a module but don't wait for it",
and I wonder if that is what should have been used here.

Doing a "range wait", with the start of the range being taken at the start of module loading
is a bit of a hack, but it'll work for the userspace expected semantics of all async stuff of
the *loaded module* be done, independent of all other modules/async stuff.
It's not as deadlocky as one might think, but it's not going to be efficient to implement.

not self-deadlocking likely solves most practical cases though

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