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. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
