Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
> On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote:
> > 
> > udev isn't doing any module loading, 'modprobe' is just being called for
> > any new module alias that shows up in the system, and all of the drivers
> > that match it then get loaded.
> > 
> > How is it a problem if a module is attempted to be loaded that is
> > already loaded?  How is it a problem if a different module is loaded for
> > a device already bound to a driver?  Both of those should be total
> > "no-ops" for the kernel.
> > 
> > But, I don't know anything about the cpu code, how is loading a module
> > causing problems?  That sounds like it needs to be fixes, as any root
> > user can load modules whenever they want, you can't protect the kernel
> > from doing that.
> > 
> 
> The issue here seems to be the dynamic binding nature of the crypto
> subsystem.  When something needs crypto, it will request the appropriate
> crypto module (e.g. crct10dif), which may race with detecting a specific
> hardware accelerator based on CPUID or device information (e.g.
> crct10dif_pclmul).
> 
> RAID has effectively the same issue, and we just "solved" it by
> compiling in all the accelerators into the top-level module.

Then there's nothing to be done in udev or kmod, right?

greg k-h