Red Hat Bugzilla – Bug 149604
modprobe return values buggy.
Last modified: 2014-03-16 22:52:27 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: We build kernel modules and for all our kernel modules we encounter this problem. The return values of modprobe are buggy. For example, a module built for the "smp" kernel must _not_ be allowed to get loaded on a "up" kernel. modprobe must return failure in this case. But what actually happens is that if we use the --force-vermagic option, the module gets loaded despite the kernel type mismatch. Whats worse is that modprobe returns success but the module is in an inconsistent state and is unusable. Ideally, what modprobe should do is this:- 1) 'modprobe <modulename>' should retun success and load the module only if all symbol versions _and_ version magic strings match. Otherwise it must return failure. 2) 'modprobe --force-vermagic <modulename>' should return success only if the module's symbols' versions match those of the running kernel _and_ it is guaranteed that the module once loaded _will_ function properly (because the symbol versions match). If this guarantee cannot be given, it must return failure. 3) 'modprobe --force-modversion <modulename> ' is free to ignore even the symbol versions and is free to return success even though its not guaranteed that the loaded module will be functional. Thanks and regards, Abhijit Toley. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Build a kernel module for the "up" kernel. 2. Try to load it on a "smp" kernel using 'modprobe <modulename>'. 3. Hopefully, that will fail. Then try to do 'modprobe --force-vermagic <modulename>' and then you should hit the bug. Actual Results: 'modprobe --force-vermagic <modulename>' will retun success (0). However, the module will be in an inconsistent state with non-zero reference count. Expected Results: 'modprobe --force-vermagic <modulename>' should have returned failure if it cannot guarantee that the loaded module will be functional. Additional info: modprobe return values are critical to the smooth functioning of our products.
I can't reproduce this. A module built against a separate kernel fails both with a normal modprobe, and with --force-vermagic. --force loads the module, which promptly oopses.
Thanks Bill. Thanks for taking a look. Could you kindly throw some light on why we would be facing these problems? Is there a special way in which to compile our modules for modprobe to show the expected behavior? We wish to support newer kernel versions of the LINUX kernel with the older versions of our modules. For that we need a way to know if our modules can be safely loaded on running kernels. We were hoping modprobe will do that for us, but unfortunately we are facing the problems I have mentioned. Thanks and regards, Abhijit Toley.
You can read the vermagic with modinfo to check for things like compilers, SMP vs. non-SMP, etc; that should give you those distinctions.
We discovered that when we built our modules against kernel trees which did not have the Module.symvers file, modprobe behaved erratically. Otherwise it is working fine now.