public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "me at serhei dot io" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug translator/10280] allow relaxing of `uname -r` matching runtime assertion ro ABI-compatible kernel series
Date: Wed, 18 Mar 2020 16:19:43 +0000	[thread overview]
Message-ID: <bug-10280-6586-2pPuGQEeWa@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-10280-6586@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=10280

--- Comment #6 from Serhei Makarov <me at serhei dot io> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

  parent reply	other threads:[~2020-03-18 16:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-10280-6586@http.sourceware.org/bugzilla/>
2017-11-28 15:44 ` fche at redhat dot com
2019-01-16 19:18 ` me at serhei dot io
2019-06-13 23:48 ` fche at redhat dot com
2020-02-14 14:10 ` fweimer at redhat dot com
2020-02-19 21:10 ` fche at redhat dot com
2020-03-18 16:19 ` me at serhei dot io [this message]
2020-05-14 21:35 ` me at serhei dot io
2020-05-20 20:35 ` me at serhei dot io
2020-05-20 20:35 ` me at serhei dot io
2009-06-14 14:41 [Bug translator/10280] New: allow relaxing of `uname -r` matching runtime assertion fche at redhat dot com
2009-07-02 13:55 ` [Bug translator/10280] allow relaxing of `uname -r` matching runtime assertion ro ABI-compatible kernel series fche at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-10280-6586-2pPuGQEeWa@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).