From: Herbert Xu <herbert@gondor.apana.org.au>
To: David Miller <davem@davemloft.net>
Cc: brandon@ifup.org, linux-crypto@vger.kernel.org, rusty@rustcorp.com.au
Subject: Re: Fixing gave up waiting for init of module libcrc32c.
Date: Sat, 20 Mar 2010 20:29:59 +0800 [thread overview]
Message-ID: <20100320122959.GA1930@gondor.apana.org.au> (raw)
In-Reply-To: <20100319.222325.260105122.davem@davemloft.net>
On Fri, Mar 19, 2010 at 10:23:25PM -0700, David Miller wrote:
>
> I hear what you're saying Herbert, but thinking about this a bit I
> really think we should make this situation work instead of fail.
I think the initial report perhaps painted this in a slight
different fashion than what it really is. The code that was
looping in module.c is not trying to load libcrc32c, but rather
it is trying to get a reference on the already-loaded libcrc32c
module.
AFAICS the only way to make it "work" would be to reload the
module in question when we can't get a reference on it. But
that would entail recursively loading a module during the process
of loading another module.
Rusty can chime in on whether this is doable.
I think I have a good guess as to why this problem is occuring
for Brandon. It is probably the result of two near-simultaneous
modprobes, one issued against libcrc32c and one against bnx2x.
The libcrc32c module is partially loaded to the point of invoking
its init function, which then tries to modprobe crc32c.
However, before this starts the modprobe on bnx2x is already in
progression. When bnx2x's loading tries to acquire a reference
on libcrc32c which it depends on, we hit the dead-lock.
So if Suse were doing some kind of parallel booting where multiple
modules may be loaded together then this could occur.
The easiest solution again would be for modprobe(8) to block the
loading of bnx2x because the module that it depends on libcrc32c
hasn't yet finished loading.
I'm open to a kernel solution too if anyone has suggestions.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2010-03-20 12:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-19 23:40 Fixing gave up waiting for init of module libcrc32c Brandon Philips
2010-03-20 1:01 ` Herbert Xu
2010-03-20 1:08 ` Herbert Xu
2010-03-20 2:46 ` David Miller
2010-03-20 3:45 ` Herbert Xu
2010-03-20 4:21 ` Brandon Philips
2010-03-20 4:24 ` Herbert Xu
2010-03-20 5:23 ` David Miller
2010-03-20 12:29 ` Herbert Xu [this message]
2010-03-20 13:16 ` Neil Horman
2010-03-29 23:06 ` Rusty Russell
2010-03-31 19:03 ` Brandon Philips
2010-03-31 23:25 ` Rusty Russell
2010-03-30 16:50 ` Brandon Philips
2010-03-30 17:47 ` Kay Sievers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100320122959.GA1930@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=brandon@ifup.org \
--cc=davem@davemloft.net \
--cc=linux-crypto@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox