Bug 149604 - (IT_69400) modprobe return values buggy.
modprobe return values buggy.
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: module-init-tools (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-02-24 08:04 EST by Abhijit Toley
Modified: 2014-03-16 22:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-14 15:13:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Abhijit Toley 2005-02-24 08:04:46 EST
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:

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.
Comment 1 Bill Nottingham 2005-02-24 14:37:25 EST
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.
Comment 2 Abhijit Toley 2005-02-25 00:34:31 EST
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.
Comment 3 Bill Nottingham 2005-02-25 13:21:56 EST
You can read the vermagic with modinfo to check for things like compilers, SMP
vs. non-SMP, etc; that should give you those distinctions.
Comment 4 Abhijit Toley 2005-04-19 01:14:35 EDT
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. 

Note You need to log in before you can comment on or make changes to this bug.