module: fix bne2 "gave up waiting for init of module libcrc32c"
authorRusty Russell <rusty@rustcorp.com.au>
Sat, 5 Jun 2010 17:17:37 +0000 (11:17 -0600)
committerRusty Russell <rusty@rustcorp.com.au>
Sat, 5 Jun 2010 01:47:37 +0000 (11:17 +0930)
commit9bea7f23952d5948f8e5dfdff4de09bb9981fb5f
tree9cb7231bcf901fe4198142b9b054ce5ae6ce34c8
parentbe593f4ce4eb1bd40e38fdc403371f149f6f12eb
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>
kernel/module.c