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,
Version-Release number of selected component (if applicable):
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.
'modprobe --force-vermagic <modulename>' will retun success (0). However,
the module will be in an inconsistent state with non-zero reference count.
'modprobe --force-vermagic <modulename>' should have returned failure if it
cannot guarantee that the loaded module will be functional.
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
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,
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.