Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 149604 (IT_69400)

Summary: modprobe return values buggy.
Product: Red Hat Enterprise Linux 4 Reporter: Abhijit Toley <abhijit.toley>
Component: module-init-toolsAssignee: Bill Nottingham <notting>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: linux26port, rvokal, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-14 19:13:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Abhijit Toley 2005-02-24 13:04:46 UTC 
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.
Comment 1 Bill Nottingham 2005-02-24 19:37:25 UTC 
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 05:34:31 UTC 
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 18:21:56 UTC 
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 05:14:35 UTC 
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.