Description of problem:
When attempting to depmod a kernel module using an "override" in a configuration file in /etc/depmod.d, the original module is selected as a higher priority, making it impossible to ever load an external module.
Version-Release number of selected component (if applicable):
kmod-20-15.el7_4.6
https://access.redhat.com/errata/RHBA-2017:3326
How reproducible:
Every time
Steps to Reproduce:
1. Create kernel module to use with override directive
2. echo "override <kmod-name> 3.10.0-* <kmod-name>" > /etc/depmod.d.<kmod-name>.conf
3. depmod
4. check /usr/lib/`uname -r`/modules.dep for <kmod-name>
Installing a kmod package should also cover steps 1-3
Actual results:
modules.dep contains original kernel module
Expected results:
modules.dep contains new module
Additional info:
Looking at depmod.c, and the function depmod_module_is_higher_priority in particular, there seems to have been a bug introduced when moving from el7_4.4 to el7_4.6.
newlen (and oldlen) were -= to cfg->dirnamelen + 1 in el7_4.4. However, in el7_4.6 they were expanded into new variables relnewlen and reloldlen which were made equal to {new,old}len - cfg->dirnamelen + 1. I believe these variables should be set equal to {new,old}len - (cfg->dirnamelen + 1) if we were to maintain the original arithmetic. Initial testing seems to prove that adding the parentheses should resolve the issue.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:0799