lkml.org 
[lkml]   [2013]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
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


\
 
 \ /
  Last update: 2013-07-20 02:01    [W:0.129 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site