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