Messages in this thread | | | Date | Mon, 31 May 2010 13:15:37 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH 2/2] module: fix bne2 "gave up waiting for init of module libcrc32c" |
| |
On Mon, 31 May 2010, Linus Torvalds wrote: > > It's entirely possible that an interim fix (if we can't just fix the > locking) is to _not_ use "strong_try_module_get()" at all, but instead > just use "try_module_get()", and then after we've dropped the > module_mutex, but _before_ we call the "init" function for the module, we > wait for all the modules that this module depends on. > > IOW, we'd link to other modules _before_ they are necessarily initialized > (their symbol tables will be as initialized as they are going to be), but > then before we call our own initialization routines we make sure that the > modules we linked to have finished theirs. > > Doesn't that sound like the logical thing to do? And it wouldn't change > any locking.
Ok, this is a two-patch series to do exactly that. It's totally untested, although I _have_ booted the result, and tested that module loading and unloading works. But I haven't tested the race condition, obviously.
It looks sane, and quite frankly, I think it's a much better design than what we have now. I also note that the old code was broken for the case of not having CONFIG_MODULE_UNLOAD - I didn't fix it, but it should be easy to do (basically, we should do the whole module dependency list regardless of whether we can unload modules or not - we _do_ need it in order to get that whole case of waiting for them to load right).
The first patch doesn't really change anything, it just cleans things up and introduces the two-way module usage list that the second patch needs in order to wait for modules that we use to initialize.
Comments? Brandon - does this work for you? I may well have missed something.
Linus
| |