Bug 1448961 - question about weak-modules and el7
Summary: question about weak-modules and el7
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: dkms
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Simone Caronni
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-08 21:01 UTC by Gary Gatling
Modified: 2017-05-19 15:05 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-19 14:16:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Gary Gatling 2017-05-08 21:01:45 UTC
Description of problem:

If I try to add a "out of tree" kernel module such as openafs or bbswitch via dkms on rhel 7 it works initially. However, once a kernel update happens a symlink is created in "weak-updates" directory. After enough kernel updates happen all the symlinks become broken as they point to a module that no longer exists. Because yum removes kernels when they become old enough. This process takes several months before enough kernel updates have happened to break the symlinks.

Is there some way to suppress or change this behaviour? I tried adding NO_WEAK_MODULES="yes" in dkms.conf but it did not seem to make any difference.


Version-Release number of selected component (if applicable):

dkms-2.3-4.20170313git974d838.el7.noarch

How reproducible:

add some third party "out of tree" kernel module via dkms. I tested openafs network file system and also a module called bbswitch which is useful for some users on optimus notebooks. But I get the same behaviour with both modules.


Steps to Reproduce:
1. install openafs-dkms via http://install.linux.ncsu.edu/pub/yum/itecs/public/openafs/7/x86_64/
2. update kernel
3. notice openafs.ko is a symlink under /usr/lib/modules/3.10.0-XXX-XX-XX.el7.x86_64/weak-updates/openafs.ko
(whatever kernel you updated to)

Actual results:

weak-modules creates a symlink to the first module it built.


Expected results:

dkms should rebuild it and not have any symlinks under weak-updates.


Additional info:

I opened bz1443217 and am preparing to open a service ticket but I wanted to check with dkms maintainer first to see if I am doing something wrong.

Everything is working fine on fedora 24+ and rhel 6. Its only a problem on rhel 7 it seems.

Comment 1 Gary Gatling 2017-05-08 21:22:16 UTC
Sorry. Slight correction. Problem also exists in rhel 6 and centos 6. But not in fedora.

Comment 2 Gary Gatling 2017-05-19 14:15:25 UTC
Hi. Sorry. After doing a lot more testing it seems the weak-modules script is not breaking dkms added modules or symlinks as long as the /boot partition is big enough. So sorry for the trouble on that.

Comment 3 Simone Caronni 2017-05-19 15:00:13 UTC
(In reply to Gary Gatling from comment #2)
> Hi. Sorry. After doing a lot more testing it seems the weak-modules script
> is not breaking dkms added modules or symlinks as long as the /boot
> partition is big enough. So sorry for the trouble on that.

Sorry for the late reply, before replying I wanted to actually check and give a proper answer. Unfortunately I'm very short on time so did not manage to actually find any time to look into the issue.

The weak-update mechanism allows you to use the same kernel module also for late kernels, as RHEL supports kABI whitelists. For example, for the xpad module I built myself:

$ rpm -qp --requires kmod-xpad-4.11-1.20170410git5376366.el7.x86_64.rpm 
/sbin/depmod
/sbin/depmod
/bin/sh
/bin/sh
/bin/sh
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
kernel(__dynamic_dev_dbg) = 0xc140ad72
kernel(__fentry__) = 0xbdfb6dbb
kernel(__init_waitqueue_head) = 0xf432dd3d
kernel(_raw_spin_lock_irqsave) = 0x9327f5ce
kernel(_raw_spin_unlock_irqrestore) = 0x08f64aa4
kernel(dev_err) = 0x0d795224
kernel(dev_get_drvdata) = 0x7cf5b2b3
kernel(dev_set_drvdata) = 0xc483a55a
kernel(dev_warn) = 0x43b38448
kernel(flush_work) = 0x8487a2b6
kernel(input_allocate_device) = 0xe8fe6cd4
kernel(input_event) = 0x2953511d
kernel(input_ff_destroy) = 0x0989b4aa
kernel(input_free_device) = 0xab72d020
kernel(input_register_device) = 0xb7d27f45
kernel(input_set_abs_params) = 0x795965a9
kernel(input_unregister_device) = 0x7304db2f
kernel(kfree) = 0x037a0cba
kernel(kmalloc_caches) = 0x98ab5c8d
kernel(kmem_cache_alloc_trace) = 0x41ec4c1a
kernel(memcpy) = 0x69acdf38
kernel(module_layout) = 0x28950ef1
kernel(mutex_lock) = 0x9abdea30
kernel(mutex_unlock) = 0x4ed12f73
kernel(param_ops_bool) = 0x1976aa06
kernel(queue_work_on) = 0x2e0d2f7f
kernel(snprintf) = 0x28318305
kernel(strlcat) = 0xf9c0b663
kernel(synchronize_sched) = 0x0c2cdbf1
kernel(system_wq) = 0x2d3385d3
kernel(usb_alloc_coherent) = 0x02a341dc
kernel(usb_alloc_urb) = 0xd324731e
kernel(usb_anchor_urb) = 0x6cd4fdc0
kernel(usb_deregister) = 0x3fbb7b80
kernel(usb_free_coherent) = 0x7c482ef1
kernel(usb_free_urb) = 0x160306a3
kernel(usb_kill_anchored_urbs) = 0xff1076fc
kernel(usb_kill_urb) = 0xc1d81556
kernel(usb_register_driver) = 0x0eaad664
kernel(usb_submit_urb) = 0x4581b950
kernel(usb_unanchor_urb) = 0xd7021da1
kernel(usb_wait_anchor_empty_timeout) = 0xe6c8b53f
rpmlib(PayloadIsXz) <= 5.2-1

As you can see it does not require any specific version, it requires kernel symbols. So if it's a weak update, the kernel gets updated but the module not if no symbols have changed.

This is quite cool and pretty unique to RHEL. I build my module, and they normally work for years without recompilation. That's why for example HP ships binary kABI kmod drivers; because on RHEL you can :)

Comment 4 Simone Caronni 2017-05-19 15:00:56 UTC
So in your case, the link allows DKMS to re-use the same module also for later kernels if it still works.

Comment 5 Gary Gatling 2017-05-19 15:05:51 UTC
Cool. Thanks a lot Simone for the explanation. Much appreciated!


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