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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
