Bug 10280 - allow relaxing of `uname -r` matching runtime assertion ro ABI-compatible kernel series
Summary: allow relaxing of `uname -r` matching runtime assertion ro ABI-compatible ker...
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks: 25580
  Show dependency treegraph
 
Reported: 2009-06-14 14:41 UTC by Frank Ch. Eigler
Modified: 2020-05-20 20:35 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2009-06-14 14:41:00 UTC
On ABI-compatible kernel series such as RHEL5, a module compiled against
an older kernel can sometimes be loaded correctly on later kernels of the
same series.  Systemtap prohibits this by checks in translate.cxx 
(c_unparser:;emit_module_init) that matches UTS_RELEASE against the
compile-time `uname -r`.  This check is valuable in some contexts, but
seems counterproductive here.  So let's give users an option to remove
this check.  

(Perhaps it could be heuristically automated if no highly release/build-specific
data such as debuginfo is used in a given script.)
Comment 1 Frank Ch. Eigler 2009-06-14 15:00:20 UTC
Oh dear, UTS_RELEASE is a compile-time value rather than a run-time value
in some cases, so the check currently there doesn't accomplish very much
at all.
Comment 2 Frank Ch. Eigler 2009-07-02 13:55:06 UTC
See also bug #10350.  An empty list of "debuginfo required" may be
used as a trigger for a notification that this script could be eligible
for ABI-portable execution.
Comment 3 Frank Ch. Eigler 2017-11-28 15:44:18 UTC
stap -DSTP_NO_VERREL_CHECK overrides one type of check;
stap -DSTP_NO_BUILDID_CHECK overrides another.
Comment 4 Serhei Makarov 2019-01-16 19:18:52 UTC
In fact, recent investigation shows that the version checking based on Modsymvers (kernel ABI match) and build-id (probed programs) may not be nearly strict enough for some cases.

To start with, I pushed a patch to force guru-mode modules (much more likely to crash on the wrong kernel version) to build with CONFIG_MODVERSIONS= and thus use the older 'vermagic' module mechanism. However, further investigation is needed to decide how the version-checking mechanisms should work.
Comment 5 Frank Ch. Eigler 2019-06-13 23:48:44 UTC
commit c8084763b75fe may be breaking stap -g modules on non-fedora kernel configs.
Comment 6 Serhei Makarov 2020-03-18 16:19:43 UTC
This issue came up again in connection with PR25580. My current thinking outlined below.

Desired: We want to compile a guru-mode module and ship the compiled module.
The module should continue to load on new kernel versions,
as long as the stap compiler would have produced the same module as before.

SystemTap compiles modules differently depending on
- kernel version (explicitly checked by #if preprocessor conditionals)
  - However, the explicit kernel-version #if are written only for already-released versions. Therefore, the appearance of a new version won't cause any of these checks to trigger.
- modsymvers (built into the kernel-module build system)
- stapconf results (may change with future kernel version or config tweaks)
- (anything else?)

Checking for modsymvers is given to us by the kernel-module build system.
Although modsymvers only tracks changes to the public kernel ABI,
SystemTap uses both public and private ABIs.
However, changes to private ABIs not detected by stapconf would
not cause the same SystemTap version to start compiling things differently.
In essence, we already assume that updating the kernel but not the SystemTap module will be safe in this situation.

For the stapconf result, we need to evaluate if the stapconf results are actually useful to guard against breakage in new kernel versions.

If they are useful, we may need to generate a table of stapconf results for each new kernel and have it be checked on module load, similarly to modsymvers. (Not every module uses every stapconf result.)

If they are not, it's sufficient to add an option to relax any explicit kernel-version checks and then close this bug.
Comment 7 Serhei Makarov 2020-05-14 21:35:45 UTC
Re-enabled the strict vermagic check for guru-mode scripts
after investigating PR24720 and re-testing the patch on PPC.

Also disabled the vacuous UTS_VERSION/UTS_RELEASE checks unless enabled with STP_ENABLE_VERREL_CHECK.

Before closing the PR, should give a bit of time to see what happens in testing,
and document in NEWS that the UTS_VERSION/UTS_RELEASE check setting is now controlled with STP_ENABLE_VERREL_CHECK.
Comment 8 Serhei Makarov 2020-05-20 20:35:36 UTC
Closing the PR as of commit c545de0a9261
Will keep an eye out for the potential issue with PR24720.
Comment 9 Serhei Makarov 2020-05-20 20:35:54 UTC
closed