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 11:38:04PM +0200, Rafael J. Wysocki wrote:
> Alas, this is not the one I'd like to apply.
> 
> With that patch applied, new device objects are created to avoid binding the
> processor driver directly to the cpu system device objects, because that
> apparently confuses udev and it starts to ignore the cpu modalias once the
> driver has been bound to any of those objects.
> 
> I've verified in the meantime that this indeed is the case.
> 
> A link to the patch in question: https://patchwork.kernel.org/patch/2830561/
> 
> Greg, I asked you some time ago whether or not it was possible for udev to stop
> autoloading modules that matched the cpu modalias after a driver had been bound
> to the cpu system device objects and you said "no".  However, this time I can
> say with certainty that that really is the case.  So, the question now is
> whether or not we can do anything in the kernel to avoid that confusion in udev
> instead of applying the patch linked above (which is beyond ugly in my not so
> humble opinion)?

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.

thanks,

greg k-h