On Tue, Jan 15, 2013 at 9:36 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > This kind of "let's randomly encourage people to write subtly buggy > code that has magical timing dependencies, so that the developer won't > likely even see it because he has fast disks etc" code is totally > unacceptable. And this code was *designed* to be that kind of buggy.
Btw, we could *possibly* do this the other way around. Wait for all async work by default, but then have a really hacky way to turn that off for modules that explicitly don't want it, because they know they can be loaded in async context, and they don't do any async work themselves. Then we could make the IO schedulers set that flag ("I know I'm loaded from async space, and I know I'm not myself doing any async init") Quite frankly, I'd still much rather prefer the automated approach - or even better, just avoiding the "load modules in async context" entirely. But at least the "I can put a huge comment about why I don't want to be waited on" would be much more acceptable than the "I need to explicitly tell the world that it needs to wait on me". So Ming Lei's patch was "easily subtly buggy by mistake" (showing that by the fact that it was indeed buggy), while the opposite model where you have to explicitly ask people not to wait for you could still be very buggy, but at least now it needs to explicitly do extra work in order to be buggy. So if an interface is fragile, it should aim to be fragile in the right way - making the fragility explicit, so that people can grep for it, and people can add comments to the particular code that marks it fragile. The default behavior should be the robust one. And if would be lovely to add a warning to the "people loaded a module from async context" case, so that we'd *see* this. Tejun, is there a good way for code to see "I'm running in async context"? Then we could do something like WARN_ON_ONCE(wait && system_state == SYSTEM_RUNNING && in_async_thread()); in kernel/kmod.c (__request_module()). That should at least warn about this whole issue happening. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html