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]

Message-ID: <Pine.LNX.4.44L0.1301151300200.11786-100000@netrider.rowland.org>
Date:	Tue, 15 Jan 2013 13:20:58 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Ming Lei <ming.lei@...onical.com>, Tejun Heo <tj@...nel.org>,
	Alex Riesen <raa.lkml@...il.com>, 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"

On Tue, 15 Jan 2013, Linus Torvalds wrote:

> Tejun, comments? You can see the whole thread on lkml, but the basic
> problem is that the module loading doing the unconditional
> async_synchronize_full() has caused problems, because we have
> 
>  - load module A
>    - module A does per-controller async discovery of its devices (eg
> scsi or ata probing)
>    - in the async thread, it initializes somethign that needs another
> module B (in this case the default IO scheduler module)
>       - modprobe for B loads the IO scheduler module successfully
>           at the end of the module load, it does
> async_synchronize_full() to make sure load_module won't return before
> the module is ready
>           *DEADLOCK*, because the async_synchronize_full() thing
> actually waits for not the module B async code (it didn't have any),
> but for the module *A* async code, which is waiting for module B to
> finish.
> 
> Now, I'll happily argue that we shouldn't have this kind of "load
> modules from random context" behavior in the kernel, and I think the
> block layer is to blame for doing the IO scheduler load at an insane
> time. So "don't do that then" would be the best solution.

It may not be so easy.  When the SCSI async thread probes the new disk, 
it has to do I/O.  So it needs to use a scheduler.

But maybe it could use a built-in trivial scheduler until the proper 
one is loaded.  Then the loading could be asynchronous.

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/