diff options
author | Rusty Russell <rusty@rustcorp.com.au> | 2010-06-05 13:17:37 -0400 |
---|---|---|
committer | Rusty Russell <rusty@rustcorp.com.au> | 2010-06-04 21:47:37 -0400 |
commit | 9bea7f23952d5948f8e5dfdff4de09bb9981fb5f (patch) | |
tree | 9cb7231bcf901fe4198142b9b054ce5ae6ce34c8 /kernel/extable.c | |
parent | be593f4ce4eb1bd40e38fdc403371f149f6f12eb (diff) |
module: fix bne2 "gave up waiting for init of module libcrc32c"
Problem: it's hard to avoid an init routine stumbling over a
request_module these days. And it's not clear it's always a bad idea:
for example, a module like kvm with dynamic dependencies on kvm-intel
or kvm-amd would be neater if it could simply request_module the right
one.
In this particular case, it's libcrc32c:
libcrc32c_mod_init
crypto_alloc_shash
crypto_alloc_tfm
crypto_find_alg
crypto_alg_mod_lookup
crypto_larval_lookup
request_module
If another module is waiting inside resolve_symbol() for libcrc32c to
finish initializing (ie. bne2 depends on libcrc32c) then it does so
holding the module lock, and our request_module() can't make progress
until that is released.
Waiting inside resolve_symbol() without the lock isn't all that hard:
we just need to pass the -EBUSY up the call chain so we can sleep
where we don't hold the lock. Error reporting is a bit trickier: we
need to copy the name of the unfinished module before releasing the
lock.
Other notes:
1) This also fixes a theoretical issue where a weak dependency would allow
symbol version mismatches to be ignored.
2) We rename use_module to ref_module to make life easier for the only
external user (the out-of-tree ksplice patches).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tim Abbot <tabbott@ksplice.com>
Tested-by: Brandon Philips <bphilips@suse.de>
Diffstat (limited to 'kernel/extable.c')
0 files changed, 0 insertions, 0 deletions