RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1133045 - Use default path for modules when loading it trough kpatch
Summary: Use default path for modules when loading it trough kpatch
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kpatch
Version: 7.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: 7.1
Assignee: Seth Jennings
QA Contact: Linqing Lu
URL:
Whiteboard:
Depends On:
Blocks: 1148851
TreeView+ depends on / blocked
 
Reported: 2014-08-22 13:56 UTC by Pablo Iranzo Gómez
Modified: 2018-12-09 18:25 UTC (History)
5 users (show)

Fixed In Version: kpatch-0.1.10-2.el7
Doc Type: Bug Fix
Doc Text:
The kpatch interface now lists both loaded and installed patch modules by modprobe name, rather than by file name. This makes it more intuitive for users to load and unload installed modules.
Clone Of:
: 1148851 (view as bug list)
Environment:
Last Closed: 2015-03-05 13:40:25 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0296 0 normal SHIPPED_LIVE kpatch bug fix and enhancement update 2015-03-05 17:33:13 UTC

Description Pablo Iranzo Gómez 2014-08-22 13:56:41 UTC 
Description of problem:

When using kpatch you can see the loaded patch modules without the full pathname, e.g.

[root@host ~]# kpatch list
Loaded patch modules:
kpatch_7_0_0_poc_el7_0

Installed patch modules:
kpatch-7-0-0-poc-el7_0.ko (3.10.0-123.4.2.el7.x86_64)
kpatch-7-0-0-poc-el7_0.ko (3.10.0-123.4.2.el7.x86_64.debug)
[root@host ~]#

So I can unload the kpatch_7_0_0_poc_el7_0 module like so:-

[root@host ~]# kpatch unload kpatch_7_0_0_poc_el7_0
disabling patch module: kpatch_7_0_0_poc_el7_0
unloading patch module: kpatch_7_0_0_poc_el7_0

[root@host ~]# kpatch list
Loaded patch modules:

Installed patch modules:
kpatch-7-0-0-poc-el7_0.ko (3.10.0-123.4.2.el7.x86_64)
kpatch-7-0-0-poc-el7_0.ko (3.10.0-123.4.2.el7.x86_64.debug)
[root@host ~]#

But now I want to reload it back in but:-

[root@host ~]# kpatch load kpatch_7_0_0_poc_el7_0
kpatch: can't find kpatch_7_0_0_poc_el7_0

It loads if I specify the full path:-

[root@host ~]# kpatch load /usr/lib/kpatch/3.10.0-123.4.2.el7.x86_64/kpatch-7-0-0-poc-el7_0.ko
loading patch module: /usr/lib/kpatch/3.10.0-123.4.2.el7.x86_64/kpatch-7-0-0-poc-el7_0.ko
[root@host ~]# kpatch list
Loaded patch modules:
kpatch_7_0_0_poc_el7_0

Installed patch modules:
kpatch-7-0-0-poc-el7_0.ko (3.10.0-123.4.2.el7.x86_64)
kpatch-7-0-0-poc-el7_0.ko (3.10.0-123.4.2.el7.x86_64.debug)
[root@host ~]#



Actual results:

- Path must be specified


Expected results:
- kpatch should use the default path for the current kernel to find the module to load.
Comment 1 Seth Jennings 2014-08-22 15:20:02 UTC 
If you do a 'kpatch load kpatch_7_0_0_poc_el7_0.ko' (note the .ko) it works.  This is misleading though since the list under 'Loaded patch modules' does not show the .ko.

I can think of two things we could do:
1) If the user passes in a patch name without .ko, add it
2) Require the .ko but change the name under 'Loaded patch modules' to include .ko so that it is clearer that the .ko is part of the name.  That also makes it match the 'Installed patch modules' output, which already displays the .ko.
Comment 2 Josh Poimboeuf 2014-08-25 19:56:06 UTC 
Another issue is that the filename with .ko removed doesn't exactly match the module name, because the kernel module code converts all '-' characters to '_'.
Comment 3 Josh Poimboeuf 2014-08-25 20:06:47 UTC 
I think we should do something similar to:

1) If the user passes in a patch name without .ko, add it

with the additional feature of converting '_' to '-' where appropriate.

Note that when converting from filename to module name, all '-' are converted to '_'.  But the reverse is not true: when converting from module name to filename, not all '_' are necessarily converted to '-'.  So when looking for a file to match the given module name, we'll have to do something like go through each installed file, convert '-' to '_', and compare with the given module name.
Comment 4 Josh Poimboeuf 2014-08-25 20:12:55 UTC 
Opened upstream issue https://github.com/dynup/kpatch/issues/371
Comment 5 Seth Jennings 2014-09-02 18:42:15 UTC 
Fix in upstream commit 1d63ce84932efda559d6d745930e1b05f446a334 included in v0.2.1.
Comment 6 Josh Poimboeuf 2014-09-02 19:21:07 UTC 
Reopening (still needs to be fixed in RHEL).
Comment 10 Seth Jennings 2014-10-13 16:38:31 UTC 
I wouldn't say it is expected, but it doesn't keep this change from fixing the problem the bug describes; namely, inconsistent output between the "installed" and "loaded" list formats and load not accepting one of the list formats.

Might be worth doing hyphen to underscore conversion in all cases though.  I'll create a patch upstream.

However, this nuance doesn't prevent the fix from addressing the issue in this bug.
Comment 11 Linqing Lu 2014-10-14 13:27:33 UTC 
That makes sense to me. Thanks~
The major issue has been fixed for sure, and minor problem about hyphen/underscore consistency would be expected to fix in upstream.

Please let me know if need a BZ to track the backport.
Comment 13 errata-xmlrpc 2015-03-05 13:40:25 UTC 
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://rhn.redhat.com/errata/RHBA-2015-0296.html
Note You need to log in before you can comment on or make changes to this bug.