Did the verification for the kernel (linux-generic) like above and based
on representative kernel modules (arch-specific and common):

noble:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04 LTS
Release:        24.04
Codename:       noble
$ uname -a
Linux testlpar1 6.8.0-35-generic #35-Ubuntu SMP Mon May 20 15:36:54 UTC 2024 
s390x s390x s390x GNU/Linux
$ sudo unzstd 
/usr/lib/debug/lib/modules/6.8.0-35-generic/kernel/arch/s390/crypto/aes_s390.ko.zst
 
/usr/lib/debug/lib/modules/6.8.0-35-generic/kernel/arch/s390/crypto/aes_s390.ko.zst:
 507329 bytes
$ readelf -wi 
/usr/lib/debug/lib/modules/6.8.0-35-generic/kernel/arch/s390/crypto/aes_s390.ko 
| grep DW_AT_produce | grep -c mbackchain
2
$ readelf -wi 
/usr/lib/debug/lib/modules/6.8.0-35-generic/kernel/arch/s390/crypto/aes_s390.ko 
| grep DW_AT_produce | grep -c no-omit-frame-pointer
0
$ sudo unzstd 
/usr/lib/debug/lib/modules/6.8.0-35-generic/kernel/fs/nfs/nfsv4.ko.zst
/usr/lib/debug/lib/modules/6.8.0-35-generic/kernel/fs/nfs/nfsv4.ko.zst: 
17383593 bytes
$ readelf -wi 
/usr/lib/debug/lib/modules/6.8.0-35-generic/kernel/fs/nfs/nfsv4.ko | grep 
DW_AT_produce | grep -c mbackchain
24
$ readelf -wi 
/usr/lib/debug/lib/modules/6.8.0-35-generic/kernel/fs/nfs/nfsv4.ko | grep 
DW_AT_produce | grep -c no-omit-frame-pointer
0

oracular:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu Oracular Oriole (development branch)
Release:        24.10
Codename:       oracular
$ uname -a
Linux s1lp14 6.11.0-4-generic #4-Ubuntu SMP Tue Aug 20 14:03:40 UTC 2024 s390x 
s390x s390x GNU/Linux
$ sudo unzstd 
/usr/lib/debug/lib/modules/6.11.0-4-generic/kernel/arch/s390/crypto/aes_s390.ko.zst
/usr/lib/debug/lib/modules/6.11.0-4-generic/kernel/arch/s390/crypto/aes_s390.ko.zst:
 529441 bytes 
$ readelf -wi 
/usr/lib/debug/lib/modules/6.11.0-4-generic/kernel/arch/s390/crypto/aes_s390.ko 
| grep DW_AT_produce | grep -c mbackchain
2
$ readelf -wi 
/usr/lib/debug/lib/modules/6.11.0-4-generic/kernel/arch/s390/crypto/aes_s390.ko 
| grep DW_AT_produce | grep -c no-omit-frame-pointer
0
$ sudo unzstd 
/usr/lib/debug/lib/modules/6.11.0-4-generic/kernel/fs/nfs/nfsv4.ko.zst
[sudo] password for ubuntu: 
/usr/lib/debug/lib/modules/6.11.0-4-generic/kernel/fs/nfs/nfsv4.ko.zst: 
18990945 bytes
$ readelf -wi 
/usr/lib/debug/lib/modules/6.11.0-4-generic/kernel/fs/nfs/nfsv4.ko  | grep 
DW_AT_produce | grep -c mbackchain
24
$ readelf -wi 
/usr/lib/debug/lib/modules/6.11.0-4-generic/kernel/fs/nfs/nfsv4.ko  | grep 
DW_AT_produce | grep -c no-omit-frame-pointer
0

Like one can see '-mbackchain' is set, but "-no-omit-frame-pointer" is
not set, hence successful verified.

Closing the affected 'linux (Ubuntu)' as 'Fix Released' - and with that
the project entry as well.


** Changed in: linux (Ubuntu Noble)
       Status: New => Fix Released

** Changed in: linux (Ubuntu Oracular)
       Status: New => Fix Released

** Changed in: ubuntu-z-systems
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2064538

Title:
  Revert back frame pointers for s390x (remove -fno-omit-frame-pointer
  but use -mbackchain)

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in dpkg package in Ubuntu:
  Fix Released
Status in glibc package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in dpkg source package in Noble:
  Fix Released
Status in glibc source package in Noble:
  Fix Released
Status in linux source package in Noble:
  Fix Released
Status in dpkg source package in Oracular:
  Fix Released
Status in glibc source package in Oracular:
  Fix Released
Status in linux source package in Oracular:
  Fix Released

Bug description:
  SRU Justification:

  [ Impact ]

   * The preferred way of doing stack unwinding on Linux on Z is via dwarf call 
frame information.
  In absence of a dwarf unwinder (as in the Linux kernel) a stack chain can be 
maintained at runtime in addition to the dwarf unwinding information.

   * This allows for simple backtrace implementations, but imposes a
  small runtime overhead. For this to work, all code that might be part
  of backtrace must be built with the -mbackchain GCC option.

   * The -fno-omit-framepointer switch is neither necessary nor helpful in this 
context.
    Having a (soft/simulated) frame pointer does not improve backtraces at all 
on IBM Z.

   * However, forcing a frame pointer via the -fno-omit-frame-pointer
  option negatively affects performance for multiple reasons: extra
  prologue/epilogue overhead and fewer shrink-wrapping opportunities.

   * Given -fno-omit-frame-pointer does not provide any improvements
  (backtraces or otherwise) and only reduces performance, -fno-omit-
  frame-pointers should not be used on IBM Z.

   * So we are facing here a performance penalty without any gain - on
  this particular platform.

   * And sometimes (in rare cases like LP#2060108) frame pointers may
  even lead to failed builds.

  [ Test Plan ]

   * Due to the above description of the impact and rationale,
     this pragmatic approach for testing is given:

   * Build the affected packages where frame-pointers should be reverted
     using the updated dpkg package (that incl. the modified build defaults)
     on (or for) this particular platform.

   * Now frame-pointer usage be checked in the following different ways:

   * 1) For the ease of use (and thanks to Julian Klode), there is this python
        test script available that allows to verify a binary in regard to
        frame pointers:
        https://gist.github.com/julian-klode/85e55553f85c410a1b856a93dce77208
        
https://gist.githubusercontent.com/julian-klode/85e55553f85c410a1b856a93dce77208/raw/488b8509e6f23fe48f917961fe711b285dcb2e28/dwprod.py
        requires python3-pyelftools

   * 2) Another more manual way is to verify based on debug symbols like this:
        - find and install the ddeb package
        - maybe extract the  file (e.g. unzstd)
        - use 'readelf -wi'
        - and grep for 'DW_AT_produce' (build options)
        - look for entries regarding frame-pointer
        The output may look similar to this:
        readelf -wi 
./usr/lib/debug/lib/modules/6.8.0-38-generic/kernel/arch/s390/crypto/aes_s390.ko
 | grep DW_AT_produce
            <23>   DW_AT_producer    : (indirect string, offset: 0x7d): GNU AS 
2.42
            <129>   DW_AT_producer    : (indirect string, offset: 0x3eef): GNU 
C11 13.2.0 -m64 -mpacked-stack -mbackchain -msoft-float -march=z13 -mtune=z16 
-mindirect-branch=thunk-extern -mfunction-return=thunk-extern 
-mindirect-branch-table -mrecord-mcount -mnop-mcount -mfentry -mzarch -g 
-gdwarf-5 -O2 -std=gnu11 -p -fshort-wchar -funsigned-char -fno-common 
-fno-strict-aliasing -fno-asynchronous-unwind-tables 
-fno-delete-null-pointer-checks -fno-allow-store-data-races 
-fno-stack-protector -ftrivial-auto-var-init=zero -fno-stack-clash-protection 
-fzero-call-used-regs=used-gpr -fno-inline-functions-called-once 
-falign-functions=8 -fstrict-flex-arrays=3 -fno-strict-overflow 
-fstack-check=no -fconserve-stack -fsanitize=bounds-strict -fsanitize=shift 
-fsanitize=bool -fsanitize=enum -fPIC

   * 3) And maybe watching the build messages / log for the build options that
        were used (but that is probably not sufficient - it's better to inspect
        the output.)

  [ Where problems could occur ]

   * The dpkg modifications could have been done erroneously.
     A dpkg test build and/or builds of other packages with the modified dpkg
     version in place would show this.

   * The settings in dpkg might be overwritten by other settings/packages.
     Tests like above, would show this.

   * One may think there could be issues in an environment where some packages
     have frame-pointer enabled and other don't.
     This is fine and was confirmed by IBM toolchain team and ours
     (as well as by a longer running <weeks> test system,
      with FP disabled in kernel, that showed no issues - like expected).

  [ Other Info ]

   * These changes were implemented during the opening of the oracular series.
     The very same changes are backported to 24.04 LTS.

   * These only affect the ppc64el and s390x architectures,
     for other architectures it's a no-change upload.

   * We didn't see any fallout for these changes during the development
     on the oracular series, and therefore don't expect any fallout or
     regressions in 24.04 LTS either.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2064538/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to