[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Mantic and Jammy built successfully in all supported architectures.
(riscv64 fails, but it also fails on mantic/jammy-release; it's OK.)

Uploaded! 
Thanks

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  Won't Fix
Status in crash source package in Mantic:
  In Progress
Status in crash source package in Noble:
  Fix Released

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility in Mantic (release kernel 6.5) and Jammy (HWE kernel 6.5) unable
  to parse the dump file. For example (there are more, in other areas):
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes:
  - 10 patches from crash 8.0.1 into Jammy
  - 02 patches from crash 8.0.2 into Jammy
  - 12 patches from crash 8.0.3 into Jammy/Mantic
  - 12 patches from crash 8.0.4 into Jammy/Mantic

  [Test Plan]

  On Jammy (LTS), which provides HWE (6.5) and release/GA (5.15) kernels,
  perform testing on both HWE (verify fixes) and GA (verify no regressions).

  There are detailed/per-commit test plans in the attachments:
  `crash_jammy_test_plan.txt.txt` and `crash_lunar_test_plan.txt`.

  A. Test the live mode (live-system form; without a dumpfile), and
  B. Test the dump mode (dumpfile form: sysrq-trigger/makedumpfile/crash):

  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "aarch64-unknown-linux-gnu".
  Type "show configuration" for configuration details.
  Find the GDB manual and other documentation resources online at:
  .

  For help, type "help".
  Type "apropos word" 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

** Description changed:

  [Impact]
- Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
+ Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility in Mantic (release kernel 6.5) and Jammy (HWE kernel 6.5) unable
+ to parse the dump file. For example (there are more, in other areas):
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==
  
  [Fix]
- It is advisable to adopt commits that address the structural changes issue.
- ==
- 
- In 8.0.1:
- - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
- - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
- - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB
- 
- In 8.0.2:
- - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing
- 
- In 8.0.3:
- - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
- - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
- - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
- - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later
- 
- In 8.0.4
- - 7750e61fdb2a Support module memory layout change on Linux 6.4
- - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
- - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added
- 
- ==
+ It is advisable to adopt commits that address the structural changes:
+ - 10 patches from crash 8.0.1 into Jammy
+ - 02 patches from crash 8.0.2 into Jammy
+ - 12 patches from crash 8.0.3 into Jammy/Mantic
+ - 12 patches from crash 8.0.4 into Jammy/Mantic
  
  [Test Plan]
  
- On Jammy (LTS), which provides HWE (6.5) and GA (5.15) kernels,
+ On Jammy (LTS), which provides HWE (6.5) and release/GA (5.15) kernels,
  perform testing on both HWE (verify fixes) and GA (verify no regressions).
  
  There are detailed/per-commit test plans in the attachments:
  `crash_jammy_test_plan.txt.txt` and `crash_lunar_test_plan.txt`.
  
- And the general sysrq-trigger/makedumpfile/crash test:
+ A. Test the live mode (live-system form; without a dumpfile), and
+ B. Test the dump mode (dumpfile form: sysrq-trigger/makedumpfile/crash):
  
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump
  
  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
  
  WARNING: VA_BITS: calculated: 46  

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Jammy: patches 0001-0012 look good too!

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  Won't Fix
Status in crash source package in Mantic:
  In Progress
Status in crash source package in Noble:
  Fix Released

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.4
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]

  On Jammy (LTS), which provides HWE (6.5) and GA (5.15) kernels,
  perform testing on both HWE (verify fixes) and GA (verify no regressions).

  There are detailed/per-commit test plans in the attachments:
  `crash_jammy_test_plan.txt.txt` and `crash_lunar_test_plan.txt`.

  And the general sysrq-trigger/makedumpfile/crash test:

  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Partial review of the Jammy debdiff.
(Still in progress.)

Started with Jammy's patches 0012-0036, which are Mantic's patches 0001-0024 
(already reviewed).
Most patches are identical, and some have context-line changes, as expected 
(8.0.2/8.0.0 delta).
Just had a few changes.

$ for ((i=1; i<=24; i++)); do 
echo "PATCH $i"
echo
diff -U0 \
  mantic/crash-8.0.2/debian/patches/lp2038249-$(printf '%04d' $i)-*.patch \
  jammy/crash-8.0.0/debian/patches/lp2038249-$(printf '%04d' 
$((i+12)))-*.patch
echo
  done 2>&1 | less

patch 13
actually a backport, context line changes

patch 4
likewise

patch 8
augment backport notes

patch 11
actually a backport, context line changes, more
indentation issue, fixed

patch 36 (same note as patch 24/mantic)

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  Won't Fix
Status in crash source package in Mantic:
  In Progress
Status in crash source package in Noble:
  Fix Released

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.4
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]

  On Jammy (LTS), which provides HWE (6.5) and GA (5.15) kernels,
  perform testing on both HWE (verify fixes) and GA (verify no regressions).

  There are detailed/per-commit test plans in the attachments:
  `crash_jammy_test_plan.txt.txt` and `crash_lunar_test_plan.txt`.

  And the general sysrq-trigger/makedumpfile/crash test:

  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Today, I tackled the Mantic debdiff (made only a few changes; below).

It's now currently building in a PPA for all supported architectures,
(ppa:mfo/lp2038249) and if all goes well I will upload it to Mantic.

Thanks!
Mauricio

---

All 24 commits are included in Noble (12 in 8.0.4 and 12 in 8.0.3).
changelog OK
DEP3 tags OK

I reviewed each commit, with the exception of the big code additions
(patches 8,16: for maple tree and module memory layout): all look OK.

I fixed up patch 24, which is originally 2 trivial and short changes,
but had like ~3800 lines of indentation/formatting changes included
(certainly this wasn't intented, and mistakes happen; so I fixed it).

$ git show 55a43bcefa20161c7e56ed0e309e90e941f47efc | wc -l
57

$ wc -l 
debian/patches/lp2038249-0024-Fix-compilation-error-and-warning-with-gcc-4.8.5.patch
3865 
debian/patches/lp2038249-0024-Fix-compilation-error-and-warning-with-gcc-4.8.5.patch

We can all learn from this -- I will check .patch files with diffstat!

I also just augmented backport notes (thanks for those) to indicate
which functions/hunks had context lines modified/adjusted/refreshed,
since the patch is big (patch 15), and clarify variables (not) used.

-+[chengen - modify x86_64.c context]
++[chengen - modify context in x86_64.c: x86_64_ORC_init() and 
x86_64_get_framesize()]

-+[chengen - initialize init_tss to zero in xen_hyper.c]
++[chengen - initialize only init_tss to zero in xen_hyper.c (there is 
no stack_base yet)]

Very importantly, the detailed test plan will be key to validate the
changes are working correctly, considering their number and size.
Thanks again for it!

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  Won't Fix
Status in crash source package in Mantic:
  In Progress
Status in crash source package in Noble:
  Fix Released

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.4
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]

  On Jammy (LTS), which provides HWE (6.5) and GA (5.15) kernels,
  perform testing on both HWE (verify fixes) and GA (verify no regressions).

  There are detailed/per-commit test plans in the attachments:
  `crash_jammy_test_plan.txt.txt` and `crash_lunar_test_plan.txt`.

  And the general sysrq-trigger/makedumpfile/crash test:

  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

** Description changed:

  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==
  
  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==
  
  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB
  
  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing
  
  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later
  
  In 8.0.4
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added
  
  ==
  
  [Test Plan]
  
+ On Jammy (LTS), which provides HWE (6.5) and GA (5.15) kernels,
+ perform testing on both HWE (verify fixes) and GA (verify no regressions).
  
  There are detailed/per-commit test plans in the attachments:
  `crash_jammy_test_plan.txt.txt` and `crash_lunar_test_plan.txt`.
  
  And the general sysrq-trigger/makedumpfile/crash test:
  
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump
  
  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
  
  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "aarch64-unknown-linux-gnu".
  Type "show configuration" for configuration details.
  Find the GDB manual and other documentation resources online at:
  .
  
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  
  crash: seek error: kernel virtual 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

crash 8.0.4 is available in noble (bug 2047861); checking the stable
releases' debdiffs.

** Changed in: crash (Ubuntu Noble)
   Status: Fix Committed => Fix Released

** Description changed:

  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==
  
  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==
  
  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB
  
  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing
  
  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later
  
- In 8.0.3++ (8.0.4 development)
+ In 8.0.4
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added
  
  ==
  
  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump
  
  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
  
  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "aarch64-unknown-linux-gnu".
  Type "show configuration" for configuration details.
  Find the GDB manual and other documentation resources online at:
  .
  
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  
  crash: seek error: kernel virtual address: d59a92d48ae8  type: "possible"
  WARNING: cannot read cpu_possible_map
  crash: seek error: kernel virtual address: 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Marking Lunar as Won't Fix (EOL).

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  Won't Fix
Status in crash source package in Mantic:
  In Progress
Status in crash source package in Noble:
  Fix Released

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.4
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]

  
  There are detailed/per-commit test plans in the attachments:
  `crash_jammy_test_plan.txt.txt` and `crash_lunar_test_plan.txt`.

  And the general sysrq-trigger/makedumpfile/crash test:

  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Updated the SRU template as requested in comment #11 with the detailed
test plans provided in comments #16-#20.

** Changed in: crash (Ubuntu Lunar)
   Status: In Progress => Won't Fix

** Changed in: crash (Ubuntu Lunar)
   Importance: Medium => Undecided

** Changed in: crash (Ubuntu Lunar)
 Assignee: Chengen Du (chengendu) => (unassigned)

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  Won't Fix
Status in crash source package in Mantic:
  In Progress
Status in crash source package in Noble:
  Fix Released

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.4
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]

  
  There are detailed/per-commit test plans in the attachments:
  `crash_jammy_test_plan.txt.txt` and `crash_lunar_test_plan.txt`.

  And the general sysrq-trigger/makedumpfile/crash test:

  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 

[Kernel-packages] [Bug 2044657] Re: Multiple data corruption issues in zfs

[Mauricio Faria de Oliveira]

Reviewed zfs-linux on mantic/jammy/focal-unapproved for acceptance.

They all look good to me (notes below, in addition to usual checks),
but I'll ask for another reviewer to provide input too, as it's ZFS.
(But I did want to provide some assistance in this long-running SRU.)

Thanks,
Mauricio

...

mantic:

The code change looks good and hasn't changed further upstream.
(There are suggested /alternatives/ in Draft state [1], but the draft 
reassures that the original, merged PR is correct.)

The [Test Plan] section provides both a specific reproducer and
general testing (in many forms), which is reassuring for -proposed
verification.

P.S.: not very polished changelog/patch files, but combined they do 
provide the information to find the LP bug and upstream/commit, usually found 
via DEP-3 headers as Origin/Bug-Ubuntu.
(Style isn't the most important thing in this case or at the moment.)

$ git log --oneline zfs-2.2.2 -- module/zfs/dnode.c | grep -m1 
'dnode_is_dirty: check dnode and its data for dirtiness'
9b9b09f452a4 dnode_is_dirty: check dnode and its data for dirtiness

jammy:

Likewise.

Regarding the point release, 22.04.4 (scheduled for Feb 22 [2]),
we are still before 'Release minus 14 (or 7) days' [3]
(when '6. Coordinate with the SRU team' and '7. ... -updates pocket 
freeze' happen).

$ git log --oneline zfs-2.1.14 -- module/zfs/dnode.c | grep -m1 
'dnode_is_dirty: check dnode and its data for dirtiness'
77b0c6f0403b dnode_is_dirty: check dnode and its data for dirtiness

focal:

The code change is a backport not from upstream (0.8 no longer 
maintained, apparently),
but comes from the original author of the patch (and noted with DEP-3 
Origin:, great!),
and looks equivalent (same code change, just in a different function 
and context).
[4]

links:
[1] https://github.com/openzfs/zfs/pull/15615
[2] https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906
[3] https://wiki.ubuntu.com/PointReleaseProcess
[4] https://github.com/robn/zfs/commit/f2f7f43a9bf4628328292f25b1663b873f271b1a

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

Title:
  Multiple data corruption issues in zfs

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Confirmed
Status in zfs-linux source package in Bionic:
  Confirmed
Status in zfs-linux source package in Focal:
  In Progress
Status in zfs-linux source package in Jammy:
  In Progress
Status in zfs-linux source package in Lunar:
  Won't Fix
Status in zfs-linux source package in Mantic:
  In Progress
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [ Impact ]

   * Multiple data corruption issues have been identified and fixed in
  ZFS. Some of them, at varying real-life reproducibility frequency have
  been deterimed to affect very old zfs releases. Recommendation is to
  upgrade to 2.2.2 or 2.1.14 or backport dnat patch alone. This is to
  ensure users get other potentially related fixes and runtime tunables
  to possibly mitigate other bugs that are related and are being fixed
  upstream for future releases.

   * For jammy the 2.1.14 upgrade will bring HWE kernel support and also
  compatiblity/support for hardened kernel builds that mitigate SLS
  (straight-line-speculation).

   * In the absence of the upgrade a cherry-pick will address this
  particular popular issue alone - without addressing other issues
  w.r.t. Redbleed / SLS, bugfixes around trim support, and other related
  improvements that were discovered and fixed around the same time as
  this popular issue.

  [ Test Plan ]

   * !!! Danger !!! use reproducer from
  https://zfsonlinux.topicbox.com/groups/zfs-discuss/T12876116b8607cdb
  and confirm if that issue is resolved or not. Do not run on production
  ZFS pools / systems.

   * autopkgtest pass (from https://ubuntu-archive-
  team.ubuntu.com/proposed-migration/ )

   * adt-matrix pass (from https://kernel.ubuntu.com/adt-matrix/ )

   * kernel regression zfs testsuite pass (from Kernel team RT test
  results summary, private)

   * zsys integration test pass (upgrade of zsys installed systems for
  all releases)

   * zsys install test pass (for daily images of LTS releases only that
  have such installer support, as per iso tracker test case)

   * LXD (ping LXD team to upgrade vendored in tooling to 2.2.2 and
  2.1.14, and test LXD on these updated kernels)

  [ Where problems could occur ]

   * Upgrade to 2.1.14 on jammy with SLS mitigations compatiblity will
  introduce slight slow down on amd64 (for hw accelerated assembly code-
  paths only in the encryption primitives)

   * Uncertain of the perfomance impact of the extra checks in dnat
  patch fix itself. Possibly affecting speed of operation, 

[Kernel-packages] [Bug 2044657] Re: Multiple data corruption issues in zfs

[Mauricio Faria de Oliveira]

** Description changed:

  [ Impact ]
  
   * Multiple data corruption issues have been identified and fixed in
  ZFS. Some of them, at varying real-life reproducibility frequency have
  been deterimed to affect very old zfs releases. Recommendation is to
  upgrade to 2.2.2 or 2.1.14 or backport dnat patch alone. This is to
  ensure users get other potentially related fixes and runtime tunables to
  possibly mitigate other bugs that are related and are being fixed
  upstream for future releases.
  
   * For jammy the 2.1.14 upgrade will bring HWE kernel support and also
  compatiblity/support for hardened kernel builds that mitigate SLS
  (straight-line-speculation).
  
-  * In the absence of the upgrade a cherry-pick will address this
+  * In the absence of the upgrade a cherry-pick will address this
  particular popular issue alone - without addressing other issues w.r.t.
  Redbleed / SLS, bugfixes around trim support, and other related
  improvements that were discovered and fixed around the same time as this
  popular issue.
  
  [ Test Plan ]
  
   * !!! Danger !!! use reproducer from
  https://zfsonlinux.topicbox.com/groups/zfs-discuss/T12876116b8607cdb and
  confirm if that issue is resolved or not. Do not run on production ZFS
  pools / systems.
  
   * autopkgtest pass (from https://ubuntu-archive-
  team.ubuntu.com/proposed-migration/ )
  
   * adt-matrix pass (from https://kernel.ubuntu.com/adt-matrix/ )
  
   * kernel regression zfs testsuite pass (from Kernel team RT test
  results summary, private)
  
   * zsys integration test pass (upgrade of zsys installed systems for all
  releases)
  
   * zsys install test pass (for daily images of LTS releases only that
  have such installer support, as per iso tracker test case)
  
   * LXD (ping LXD team to upgrade vendored in tooling to 2.2.2 and
  2.1.14, and test LXD on these updated kernels)
  
  [ Where problems could occur ]
  
   * Upgrade to 2.1.14 on jammy with SLS mitigations compatiblity will
  introduce slight slow down on amd64 (for hw accelerated assembly code-
  paths only in the encryption primitives)
  
   * Uncertain of the perfomance impact of the extra checks in dnat patch
  fix itself. Possibly affecting speed of operation, at the benefit of
  correctness.
  
+  * The cherry-picked patch ("dnat"? dnode) changes the dirty data check, but
+only makes it stronger and not weaker, thus if it were incorrect, likely
+only performance would be impacted (and it is unlikely to be incorrect
+given upstream reviews and attention to data corruption issues; also,
+there are no additional changes to that function upstream)
+ 
  [ Other Info ]
  
   * https://github.com/openzfs/zfs/pull/15571 is most current
  consideration of affairs

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

Title:
  Multiple data corruption issues in zfs

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Confirmed
Status in zfs-linux source package in Bionic:
  Confirmed
Status in zfs-linux source package in Focal:
  In Progress
Status in zfs-linux source package in Jammy:
  In Progress
Status in zfs-linux source package in Lunar:
  Won't Fix
Status in zfs-linux source package in Mantic:
  In Progress
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [ Impact ]

   * Multiple data corruption issues have been identified and fixed in
  ZFS. Some of them, at varying real-life reproducibility frequency have
  been deterimed to affect very old zfs releases. Recommendation is to
  upgrade to 2.2.2 or 2.1.14 or backport dnat patch alone. This is to
  ensure users get other potentially related fixes and runtime tunables
  to possibly mitigate other bugs that are related and are being fixed
  upstream for future releases.

   * For jammy the 2.1.14 upgrade will bring HWE kernel support and also
  compatiblity/support for hardened kernel builds that mitigate SLS
  (straight-line-speculation).

   * In the absence of the upgrade a cherry-pick will address this
  particular popular issue alone - without addressing other issues
  w.r.t. Redbleed / SLS, bugfixes around trim support, and other related
  improvements that were discovered and fixed around the same time as
  this popular issue.

  [ Test Plan ]

   * !!! Danger !!! use reproducer from
  https://zfsonlinux.topicbox.com/groups/zfs-discuss/T12876116b8607cdb
  and confirm if that issue is resolved or not. Do not run on production
  ZFS pools / systems.

   * autopkgtest pass (from https://ubuntu-archive-
  team.ubuntu.com/proposed-migration/ )

   * adt-matrix pass (from https://kernel.ubuntu.com/adt-matrix/ )

   * kernel regression zfs testsuite pass (from Kernel team RT test
  results summary, private)

   * zsys integration test pass (upgrade of zsys installed systems for
  all releases)

   * zsys 

[Kernel-packages] [Bug 2044657] Re: Multiple data corruption issues in zfs

[Mauricio Faria de Oliveira]

Hey Chris,

> ... the primary way that users get zfs in Ubuntu is via the module built with 
> the *kernel* image. 
> ... fixing that requires a zfs-linux upload and then a further kernel upload 
> to pull in the new zfs.

Yes, fixing the zfs modules shipped with the kernel packages require
uploads for zfs-linux and kernel packages.

Additionally, users can build zfs modules locally with the zfs-dkms
package (from zfs-linux; similarly to the kernel package build).

This may be useful after the new zfs-linux is available but before a new
kernel package (based on it) is avaiable.

Hope this helps!

For reference,

$ lxc launch ubuntu:mantic --vm -c limits.cpu=2 -c limits.memory=2GiB -c 
security.secureboot=false mantic-vm-zfs
$ lxc shell mantic-vm-zfs

# modinfo zfs | head -n2
filename:   /lib/modules/6.5.0-15-generic/kernel/zfs/zfs.ko.zst
version:2.2.0-0ubuntu1~23.10

# dpkg -l | grep zfs
#

# apt-cache show zfs-dkms | grep -m1 Source:
Source: zfs-linux

# apt update && apt install --yes zfs-dkms
...
Setting up zfs-dkms (2.2.0-0ubuntu1~23.10.1) ...
Loading new zfs-2.2.0 DKMS files...
Building for 6.5.0-15-generic
Building initial module for 6.5.0-15-generic
Done.
...

# modinfo zfs | head -n2
filename:   /lib/modules/6.5.0-15-generic/updates/dkms/zfs.ko.zst
version:2.2.0-0ubuntu1~23.10.1

# modprobe zfs

# cat /sys/module/zfs/version
2.2.0-0ubuntu1~23.10.1

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

Title:
  Multiple data corruption issues in zfs

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Confirmed
Status in zfs-linux source package in Bionic:
  Confirmed
Status in zfs-linux source package in Focal:
  In Progress
Status in zfs-linux source package in Jammy:
  In Progress
Status in zfs-linux source package in Lunar:
  Won't Fix
Status in zfs-linux source package in Mantic:
  In Progress
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [ Impact ]

   * Multiple data corruption issues have been identified and fixed in
  ZFS. Some of them, at varying real-life reproducibility frequency have
  been deterimed to affect very old zfs releases. Recommendation is to
  upgrade to 2.2.2 or 2.1.14 or backport dnat patch alone. This is to
  ensure users get other potentially related fixes and runtime tunables
  to possibly mitigate other bugs that are related and are being fixed
  upstream for future releases.

   * For jammy the 2.1.14 upgrade will bring HWE kernel support and also
  compatiblity/support for hardened kernel builds that mitigate SLS
  (straight-line-speculation).

   * In the absence of the upgrade a cherry-pick will address this
  particular popular issue alone - without addressing other issues
  w.r.t. Redbleed / SLS, bugfixes around trim support, and other related
  improvements that were discovered and fixed around the same time as
  this popular issue.

  [ Test Plan ]

   * !!! Danger !!! use reproducer from
  https://zfsonlinux.topicbox.com/groups/zfs-discuss/T12876116b8607cdb
  and confirm if that issue is resolved or not. Do not run on production
  ZFS pools / systems.

   * autopkgtest pass (from https://ubuntu-archive-
  team.ubuntu.com/proposed-migration/ )

   * adt-matrix pass (from https://kernel.ubuntu.com/adt-matrix/ )

   * kernel regression zfs testsuite pass (from Kernel team RT test
  results summary, private)

   * zsys integration test pass (upgrade of zsys installed systems for
  all releases)

   * zsys install test pass (for daily images of LTS releases only that
  have such installer support, as per iso tracker test case)

   * LXD (ping LXD team to upgrade vendored in tooling to 2.2.2 and
  2.1.14, and test LXD on these updated kernels)

  [ Where problems could occur ]

   * Upgrade to 2.1.14 on jammy with SLS mitigations compatiblity will
  introduce slight slow down on amd64 (for hw accelerated assembly code-
  paths only in the encryption primitives)

   * Uncertain of the perfomance impact of the extra checks in dnat
  patch fix itself. Possibly affecting speed of operation, at the
  benefit of correctness.

  [ Other Info ]

   * https://github.com/openzfs/zfs/pull/15571 is most current
  consideration of affairs

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044657/+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

[Kernel-packages] [Bug 2044657] Re: Multiple data corruption issues in zfs

[Mauricio Faria de Oliveira]

** Changed in: zfs-linux (Ubuntu Lunar)
   Importance: Medium => Undecided

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

Title:
  Multiple data corruption issues in zfs

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Confirmed
Status in zfs-linux source package in Bionic:
  Confirmed
Status in zfs-linux source package in Focal:
  In Progress
Status in zfs-linux source package in Jammy:
  In Progress
Status in zfs-linux source package in Lunar:
  Won't Fix
Status in zfs-linux source package in Mantic:
  In Progress
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [ Impact ]

   * Multiple data corruption issues have been identified and fixed in
  ZFS. Some of them, at varying real-life reproducibility frequency have
  been deterimed to affect very old zfs releases. Recommendation is to
  upgrade to 2.2.2 or 2.1.14 or backport dnat patch alone. This is to
  ensure users get other potentially related fixes and runtime tunables
  to possibly mitigate other bugs that are related and are being fixed
  upstream for future releases.

   * For jammy the 2.1.14 upgrade will bring HWE kernel support and also
  compatiblity/support for hardened kernel builds that mitigate SLS
  (straight-line-speculation).

   * In the absence of the upgrade a cherry-pick will address this
  particular popular issue alone - without addressing other issues
  w.r.t. Redbleed / SLS, bugfixes around trim support, and other related
  improvements that were discovered and fixed around the same time as
  this popular issue.

  [ Test Plan ]

   * !!! Danger !!! use reproducer from
  https://zfsonlinux.topicbox.com/groups/zfs-discuss/T12876116b8607cdb
  and confirm if that issue is resolved or not. Do not run on production
  ZFS pools / systems.

   * autopkgtest pass (from https://ubuntu-archive-
  team.ubuntu.com/proposed-migration/ )

   * adt-matrix pass (from https://kernel.ubuntu.com/adt-matrix/ )

   * kernel regression zfs testsuite pass (from Kernel team RT test
  results summary, private)

   * zsys integration test pass (upgrade of zsys installed systems for
  all releases)

   * zsys install test pass (for daily images of LTS releases only that
  have such installer support, as per iso tracker test case)

   * LXD (ping LXD team to upgrade vendored in tooling to 2.2.2 and
  2.1.14, and test LXD on these updated kernels)

  [ Where problems could occur ]

   * Upgrade to 2.1.14 on jammy with SLS mitigations compatiblity will
  introduce slight slow down on amd64 (for hw accelerated assembly code-
  paths only in the encryption primitives)

   * Uncertain of the perfomance impact of the extra checks in dnat
  patch fix itself. Possibly affecting speed of operation, at the
  benefit of correctness.

  [ Other Info ]

   * https://github.com/openzfs/zfs/pull/15571 is most current
  consideration of affairs

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044657/+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

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

crash 8.0.4 accepted to noble-proposed, marking as Fix Committed
https://launchpad.net/ubuntu/+source/crash/8.0.4-1ubuntu1

** Also affects: crash (Ubuntu Noble)
   Importance: Medium
 Assignee: Mauricio Faria de Oliveira (mfo)
   Status: In Progress

** Changed in: crash (Ubuntu Noble)
   Status: In Progress => Fix Committed

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Fix Committed
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  In Progress
Status in crash source package in Mantic:
  In Progress
Status in crash source package in Noble:
  Fix Committed

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

The crash 8.0.4 merge in bug 2047861 looks good, it passed
autopkgtests/manual tests, and is now waiting on review/sponsoring for
Noble.

Once accepted/released to Noble, this should unblock the SRUs (which have 
patches from 8.0.4).
I'll continue the SRU debdiff reviews for now.

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  In Progress
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  In Progress
Status in crash source package in Mantic:
  In Progress

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show 

[Kernel-packages] [Bug 2047861] Re: Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

Tested in dump file form in s390x; working.

s390x
-

vm

SERIES=noble
ARCH=s390x
DISK=${SERIES}_${ARCH}.qcow2

wget 
https://cloud-images.ubuntu.com/$SERIES/current/${SERIES}-server-cloudimg-${ARCH}.img
qemu-img create -F qcow2 -b ${SERIES}-server-cloudimg-${ARCH}.img -f 
qcow2 $DISK 8G

sudo apt install -y qemu-system-s390x

qemu-system-s390x \
  -machine s390-ccw-virtio -cpu qemu \
\
-smp cpus=2 -m 2048 \
-nodefaults -no-user-config \
-nographic -serial stdio \
\
-drive file=$DISK,if=none,id=drive0 \
-device virtio-blk,drive=drive0 \
\
-drive file=test-cidata.iso,media=cdrom \
\
-netdev user,hostfwd=::4-:22,id=net0 \
-device virtio-net,netdev=net0

$ ssh ubuntu@127.0.0.1 -p 4

$ lsb_release -cs
No LSB modules are available.
noble

$ uname -m
s390x

$ uname -rv
6.6.0-14-generic #14-Ubuntu SMP Thu Nov 30 09:46:34 UTC 2023

kdump-tools

sudo apt update && sudo apt install -y linux-crashdump # No, Yes
sudo sed '/^parameters =/ s/$/ crashkernel=512M/' -i /etc/zipl.conf
sudo zipl && sudo reboot

$ sudo dmesg | grep 'crashkernel.*RAM'
[1.176382] setup: Reserving 512MB of memory at 1509MB for 
crashkernel (System RAM: 1536MB)

$ sudo kdump-config status
current state   : ready to kdump

crashdump

$ echo c | sudo tee /proc/sysrq-trigger

$ find /var/crash
/var/crash
/var/crash/kexec_cmd
/var/crash/kdump_lock
/var/crash/linux-image-6.6.0-14-generic-202401091639.crash
/var/crash/202401091639
/var/crash/202401091639/dmesg.202401091639
/var/crash/202401091639/dump.202401091639

debug symbols

dpkg -l | awk '$2 ~ /linux-image-[0-9.-]+-generic/ { print $2, $3}' \
  | while read pkg version; do \
  dbgpkg="linux-image-${pkg#linux-image-}-dbgsym"; \
  arch=$(dpkg --print-architecture); \
  wget 
"https://launchpad.net/ubuntu/+archive/primary/+files/${dbgpkg}_${version}_${arch}.ddeb;;
 \
done

ar p linux-image-*-dbgsym_*.ddeb data.tar.xz | tar xJ
--wildcards './usr/lib/debug/boot/vmlinux-*-generic'

crash

sudo add-apt-repository -y ppa:mfo/lp2047861-noble-crash && sudo
apt install -y crash

# dpkg -s crash | grep Version:
Version: 8.0.4-1ubuntu1

# crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...

  KERNEL: ./usr/lib/debug/boot/vmlinux-6.6.0-14-generic
DUMPFILE: /var/crash/202401091639/dump.202401091639  [PARTIAL DUMP]
CPUS: 2
DATE: Tue Jan  9 16:36:47 UTC 2024
  UPTIME: 00:06:08
LOAD AVERAGE: 2.56, 2.20, 1.11
   TASKS: 148
NODENAME: test
 RELEASE: 6.6.0-14-generic
 VERSION: #14-Ubuntu SMP Thu Nov 30 09:46:34 UTC 2023
 MACHINE: s390x  (unknown Mhz)
  MEMORY: 2 GB
   PANIC: "Kernel panic - not syncing: sysrq triggered crash"
 PID: 1615
 COMMAND: "tee"
TASK: 4bd2400  [THREAD_INFO: 4bd2400]
 CPU: 0
   STATE: TASK_RUNNING (PANIC)

crash> bt
PID: 1615 TASK: 4bd2400   CPU: 0COMMAND: "tee"
 LOWCORE INFO:
  -psw  : 0x0400c0018000 0x00126220
  -function : __do_machine_kdump at 126220
  -prefix   : 0x026e8000
  -cpu timer: 0x7ea07b16f64d
  -clock cmp: 0x796343ea7b0db800
  -general registers:
 0x026bd400 0x026bd400
 0x00126220 0x7f239800
 00 00
 0x7f239800 0x01743958
 0x7f239800 00
 0x01743c90 0x0002
 0x03ff960d9c80 0x00fa24d0
 0x001263ee 0x026b7db8
  -access registers:
 0x03ff 0x962fa760 00 00
 00 00 00 00
 00 00 00 00
 00 00 00 00
  -control registers:
 0x14166a10 0x020ec007
 0x000ff140 00
 0x 0x000ff140
 0x3000 0x0474c1c7
 0x8000 00
 00 00
 00 0x020ec007
 0xdb00 0x000ff000
  -floating point registers:
 0x02aa1fe4e383 0x5554462d38004c43
 0x03ff960db4c3 

[Kernel-packages] [Bug 2047861] Re: Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

Autopkgtests (live system form) PASS in amd64, arm64, ppc64el, s390x (armhf 
skipped) [comment #3]
Manual tests (dump file form) PASS in amd64, arm64, ppc64el, s390x [comments 
#4, #5, #6, #7]

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

Title:
   Merge crash 8.0.4-1 into Noble

Status in crash package in Ubuntu:
  In Progress

Bug description:
  $ rmadison -a source crash | grep noble
   crash | 8.0.3+ds1-3ubuntu1 | noble  | source

  $ rmadison -a source -u debian -s unstable crash
  crash  | 8.0.4-1   | unstable   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2047861/+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

[Kernel-packages] [Bug 2047861] Re: Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

Tested in dump file form in ppc64el; working.

ppc64el
---

vm

SERIES=noble
ARCH=ppc64el
DISK=${SERIES}_${ARCH}.qcow2

wget 
https://cloud-images.ubuntu.com/$SERIES/current/${SERIES}-server-cloudimg-${ARCH}.img
qemu-img create -F qcow2 -b ${SERIES}-server-cloudimg-${ARCH}.img -f 
qcow2 $DISK 8G

sudo apt install -y qemu-system-ppc

qemu-system-ppc64 \
  -machine pseries -cpu POWER10 \
\
-smp cpus=2 -m 2048 \
-nodefaults -no-user-config \
-nographic -serial stdio \
\
-drive file=$DISK,if=none,id=drive0 \
-device virtio-blk,drive=drive0 \
\
-drive file=test-cidata.iso,media=cdrom \
\
-netdev user,hostfwd=::3-:22,id=net0 \
-device virtio-net,netdev=net0

$ ssh ubuntu@127.0.0.1 -p 3

$ lsb_release -cs
No LSB modules are available.
noble

$ uname -m
ppc64le

$ uname -rv
6.5.0-9-generic #9-Ubuntu SMP Fri Oct  6 20:21:54 UTC 2023

kdump-tools

sudo apt update && sudo apt install -y linux-crashdump # No, Yes
sudo sed 's/crashkernel=[^" ]\+/crashkernel=512M/' -i 
/etc/default/grub.d/kdump-tools.cfg
sudo update-grub && sudo reboot

...

$ sudo dmesg | grep 'crashkernel.*RAM'
[0.00] Reserving 512MB of memory at 512MB for crashkernel 
(System RAM: 2048MB)


$ sudo kdump-config status
current state   : ready to kdump

crashdump

$ echo c | sudo tee /proc/sysrq-trigger

$ find /var/crash
/var/crash
/var/crash/202401082101
/var/crash/202401082101/dmesg.202401082101
/var/crash/202401082101/dump.202401082101
/var/crash/kexec_cmd
/var/crash/kdump_lock


debug symbols

dpkg -l | awk '$2 ~ /linux-image-[0-9.-]+-generic/ { print $2, $3}' \
  | while read pkg version; do \
  dbgpkg="${pkg}-dbgsym"; \
  arch=$(dpkg --print-architecture); \
  wget 
"https://launchpad.net/ubuntu/+archive/primary/+files/${dbgpkg}_${version}_${arch}.ddeb;;
 \
done

ar p linux-image-*-dbgsym_*.ddeb data.tar.xz | tar xJ
--wildcards './usr/lib/debug/boot/vmlinux-*-generic'

crash

sudo add-apt-repository -y ppa:mfo/lp2047861-noble-crash && sudo
apt install -y crash

$ dpkg -s crash | grep Version:
Version: 8.0.4-1ubuntu1

$ crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
  KERNEL: ./usr/lib/debug/boot/vmlinux-6.6.0-14-generic
DUMPFILE: /var/crash/202401082101/dump.202401082101  [PARTIAL DUMP]
CPUS: 2
DATE: Mon Jan  8 21:00:05 UTC 2024
  UPTIME: 00:20:30
LOAD AVERAGE: 0.12, 0.15, 0.39
   TASKS: 140
NODENAME: test
 RELEASE: 6.6.0-14-generic
 VERSION: #14-Ubuntu SMP Thu Nov 30 10:29:25 UTC 2023
 MACHINE: ppc64le  (1000 Mhz)
  MEMORY: 2 GB
   PANIC: "Kernel panic - not syncing: sysrq triggered crash"
 PID: 1174
 COMMAND: "tee"
TASK: c00047f89900  [THREAD_INFO: c00047f89900]
 CPU: 1
   STATE: TASK_RUNNING (PANIC)

crash> bt
PID: 1174 TASK: c00047f89900  CPU: 1COMMAND: "tee"
 R0:  c0305af8R1:  c00047df7890R2:  c2162b00
 R3:  c00047df78a8R4:  R5:  
 R6:  c00047df7a58R7:  R8:  0001
 R9:  cec87000R10: R11: 
 R12: R13: c0007fffee80R14: 
 R15: dfc4R16: 182cb62e2458R17: 0080
 R18: 0081R19: 7fffe1a2c5d8R20: 7fffe1a2c5a0
 R21: R22: 0002R23: 0001
 R24: c3aa0390R25: R26: 0004
 R27: c38a4a20R28: c3cbace0R29: c3cbad20
 R30: c3d12b00R31: 
 NIP: c0303904MSR: 80009033OR3: 
 CTR: LR:  c0305af8XER: 20040004
 CCR: 24048200MQ:  0001DAR: 
 DSISR:  Syscall Result: 
 [NIP  : crash_setup_regs+84]
 [LR   : __crash_kexec+152]
 #0 [c00047df7890] crash_setup_regs at c0303904
crash> quit

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

Title:
   Merge crash 8.0.4-1 into Noble

[Kernel-packages] [Bug 2047861] Re: Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

Tested in dump file form in arm64; working.

arm64
-

vm

SERIES=noble
ARCH=arm64
DISK=${SERIES}_${ARCH}.qcow2

wget 
https://cloud-images.ubuntu.com/$SERIES/current/${SERIES}-server-cloudimg-${ARCH}.img
qemu-img create -F qcow2 -b ${SERIES}-server-cloudimg-${ARCH}.img -f 
qcow2 $DISK 8G

sudo apt install -y qemu-system-arm qemu-efi

dd if=/dev/zero of=flash1.img bs=1M count=64
dd if=/dev/zero of=flash0.img bs=1M count=64
dd if=/usr/share/qemu-efi/QEMU_EFI.fd of=flash0.img conv=notrunc

qemu-system-aarch64 \
-machine virt -cpu cortex-a57 \
-pflash flash0.img -pflash flash1.img \
\
-smp cpus=2 -m 2048 \
-nodefaults -no-user-config \
-nographic -serial stdio \
\
-drive file=$DISK,if=none,id=drive0 \
-device virtio-blk-device,drive=drive0 \
\
-drive file=test-cidata.iso,media=cdrom \
\
-netdev user,hostfwd=::2-:22,id=net0 \
-device virtio-net-device,netdev=net0

$ ssh ubuntu@127.0.0.1 -p 2

$ lsb_release -cs
No LSB modules are available.
noble

$ uname -m
aarch64

$ uname -rv
6.6.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 30 10:53:08 UTC 
2023

kdump-tools

sudo apt update && sudo apt install -y linux-crashdump # No, Yes
sudo sed 's/crashkernel=[^" ]\+/crashkernel=512M/' -i 
/etc/default/grub.d/kdump-tools.cfg
sudo update-grub && sudo reboot

$ sudo dmesg | grep 'crashkernel reserved:'
[0.00] crashkernel reserved: 0x8980 - 
0xa980 (512 MB)

$ sudo kdump-config status
current state   : ready to kdump

crashdump

$ echo c | sudo tee /proc/sysrq-trigger

$ find /var/crash
/var/crash
/var/crash/kexec_cmd
/var/crash/202401082101
/var/crash/202401082101/dmesg.202401082101
/var/crash/202401082101/dump.202401082101
/var/crash/kdump_lock
/var/crash/linux-image-6.6.0-14-generic-202401082101.crash

debug symbols

dpkg -l | awk '$2 ~ /linux-image-[0-9.-]+-generic/ { print $2, $3}' \
  | while read pkg version; do \
  dbgpkg="linux-image-unsigned-${pkg#linux-image-}-dbgsym"; \
  arch=$(dpkg --print-architecture); \
  wget 
"https://launchpad.net/ubuntu/+archive/primary/+files/${dbgpkg}_${version}_${arch}.ddeb;;
 \
done

ar p linux-image-unsigned-*-dbgsym_*.ddeb data.tar.xz | tar xJ
--wildcards './usr/lib/debug/boot/vmlinux-*-generic'

crash

sudo add-apt-repository -y ppa:mfo/lp2047861-noble-crash && sudo
apt install -y crash

$ dpkg -s crash | grep Version:
Version: 8.0.4-1ubuntu1

$ crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
  KERNEL: ./usr/lib/debug/boot/vmlinux-6.6.0-14-generic
DUMPFILE: /var/crash/202401082101/dump.202401082101  [PARTIAL DUMP]
CPUS: 2
DATE: Mon Jan  8 20:58:35 UTC 2024
  UPTIME: 00:24:51
LOAD AVERAGE: 0.08, 0.15, 0.67
   TASKS: 127
NODENAME: test
 RELEASE: 6.6.0-14-generic
 VERSION: #14-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 30 10:53:08 UTC 
2023
 MACHINE: aarch64  (unknown Mhz)
  MEMORY: 2 GB
   PANIC: "Kernel panic - not syncing: sysrq triggered crash"
 PID: 4928
 COMMAND: "tee"
TASK: 00d13300  [THREAD_INFO: 00d13300]
 CPU: 0
   STATE: TASK_RUNNING (PANIC)

crash> bt
PID: 4928 TASK: 00d13300  CPU: 0COMMAND: "tee"
 #0 [800083f63980] machine_kexec at 800080042e70
 #1 [800083f63b10] __crash_kexec at 8000802017a0
 #2 [800083f63b90] panic at 8000800c8b68
 #3 [800083f63c20] sysrq_handle_crash at 800080d3a81c
 #4 [800083f63c30] __handle_sysrq at 800080d3b694
 #5 [800083f63ca0] write_sysrq_trigger at 800080d3c1d8
 #6 [800083f63cc0] proc_reg_write at 8000805d4688
 #7 [800083f63d40] vfs_write at 8000804faa48
 #8 [800083f63d90] ksys_write at 8000804faec4
 #9 [800083f63dc0] __arm64_sys_write at 8000804fafac
#10 [800083f63e10] invoke_syscall at 800080033d68
#11 [800083f63e40] el0_svc_common.constprop.0 at 800080033e60
#12 [800083f63e70] do_el0_svc at 800080033f7c
#13 [800083f63e80] el0_svc at 80008158286c
#14 [800083f63ea0] el0t_64_sync_handler at 800081582f54
#15 [800083f63fe0] el0t_64_sync at 800080011e44
 PC: e295c3915c28   LR: e295c38abb6c   SP: cb160ac0
X29: cb160ac0  X28: 

[Kernel-packages] [Bug 2047861] Re: Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

** Merge proposal linked:
   https://code.launchpad.net/~mfo/ubuntu/+source/crash/+git/crash/+merge/458192

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

Title:
   Merge crash 8.0.4-1 into Noble

Status in crash package in Ubuntu:
  In Progress

Bug description:
  $ rmadison -a source crash | grep noble
   crash | 8.0.3+ds1-3ubuntu1 | noble  | source

  $ rmadison -a source -u debian -s unstable crash
  crash  | 8.0.4-1   | unstable   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2047861/+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

[Kernel-packages] [Bug 2047861] Re: Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

Autopkgtests above are in live system form.
Tested in dump file form in amd64; working.

# crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
  KERNEL: ./usr/lib/debug/boot/vmlinux-6.6.0-14-generic
DUMPFILE: /var/crash/202401081708/dump.202401081708  [PARTIAL DUMP]
CPUS: 2
DATE: Mon Jan  8 17:08:44 UTC 2024
  UPTIME: 00:01:58
LOAD AVERAGE: 0.18, 0.15, 0.06
   TASKS: 168
NODENAME: mfo-noble-vm
 RELEASE: 6.6.0-14-generic
 VERSION: #14-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 30 10:27:29 UTC 
2023
 MACHINE: x86_64  (1997 Mhz)
  MEMORY: 2 GB
   PANIC: "Kernel panic - not syncing: sysrq triggered crash"
 PID: 4587
 COMMAND: "bash"
TASK: 888005c6  [THREAD_INFO: 888005c6]
 CPU: 1
   STATE: TASK_RUNNING (PANIC)

crash> bt
PID: 4587 TASK: 888005c6  CPU: 1COMMAND: "bash"
 #0 [c9fb7ba0] machine_kexec at 862b05eb
 #1 [c9fb7c00] __crash_kexec at 8641abe3
 #2 [c9fb7cc8] panic at 862f8be4
 #3 [c9fb7d48] sysrq_handle_crash at 86ca64ca
 #4 [c9fb7d58] __handle_sysrq at 86ca6ca3
 #5 [c9fb7da0] write_sysrq_trigger at 86ca74e8
 #6 [c9fb7db8] proc_reg_write at 8678060c
 #7 [c9fb7dd8] vfs_write at 866c4472
 #8 [c9fb7e78] ksys_write at 866c4b73
 #9 [c9fb7eb8] __x64_sys_write at 866c4c29
#10 [c9fb7ec8] do_syscall_64 at 8734a64c
#11 [c9fb7f50] entry_SYSCALL_64_after_hwframe at 
874000e6
RIP: 747d04f1b214  RSP: 7ffd128231c8  RFLAGS: 0202
RAX: ffda  RBX: 0002  RCX: 747d04f1b214
RDX: 0002  RSI: 62040a0a75a0  RDI: 0001
RBP: 62040a0a75a0   R8: 0073   R9: 
R10:   R11: 0202  R12: 0002
R13: 747d04fff5c0  R14: 747d04ffcf20  R15: 
ORIG_RAX: 0001  CS: 0033  SS: 002b
crash> quit

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

Title:
   Merge crash 8.0.4-1 into Noble

Status in crash package in Ubuntu:
  In Progress

Bug description:
  $ rmadison -a source crash | grep noble
   crash | 8.0.3+ds1-3ubuntu1 | noble  | source

  $ rmadison -a source -u debian -s unstable crash
  crash  | 8.0.4-1   | unstable   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2047861/+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

[Kernel-packages] [Bug 2047861] Re: Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

Autopkgtests PASS from PPA:

$ DIR='https://autopkgtest.ubuntu.com/results/autopkgtest-noble-mfo-
lp2047861-noble-crash'

$ curl -sf "$DIR/?format=plain" | grep result.tar | while read TAR; do echo 
"ARCH: $(echo $TAR | cut -d/ -f2)"; curl -sf "$DIR/$TAR" | tar xO summary; done
ARCH: amd64
live PASS
ARCH: amd64
live PASS
ARCH: arm64
live PASS
ARCH: armhf
live SKIP Test requires machine-level isolation but testbed 
does not provide that
ARCH: ppc64el
live PASS
ARCH: s390x
live PASS

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

Title:
   Merge crash 8.0.4-1 into Noble

Status in crash package in Ubuntu:
  In Progress

Bug description:
  $ rmadison -a source crash | grep noble
   crash | 8.0.3+ds1-3ubuntu1 | noble  | source

  $ rmadison -a source -u debian -s unstable crash
  crash  | 8.0.4-1   | unstable   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2047861/+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

[Kernel-packages] [Bug 2046082] Re: zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

[Mauricio Faria de Oliveira]

Verification done for mantic-proposed.
All matches of the string are correct.

$ lxc launch ubuntu:mantic mantic-zed
$ lxc shell mantic-zed

# add-apt-repository -y -p proposed
# apt install -t mantic-proposed -y zfs-zed

# dpkg -s zfs-zed | grep Version:
Version: 2.2.0-0ubuntu1~23.10.1

# grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
#ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

# dpkg -L zfs-zed | xargs grep ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT 
2>/dev/null | sort
/etc/zfs/zed.d/zed.rc:#ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1
/usr/lib/zfs-linux/zed.d/statechange-slot_off.sh:#   2: 
ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT disabled
/usr/lib/zfs-linux/zed.d/statechange-slot_off.sh:# 
ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT is set in zed.rc, and the disk gets
/usr/lib/zfs-linux/zed.d/statechange-slot_off.sh:if [ 
"${ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT}" != "1" ] ; then

# dpkg -L zfs-zed | xargs grep ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT 
2>/dev/null | sort
#

** Tags added: verification-done-mantic

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

Title:
  zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Mantic:
  Fix Committed
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [Impact]

   * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
     ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
     in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.

   * This could be fixed in Ubuntu before users start adopting it.

  [Test Plan]

   * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.

   * Actual:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

   * Expected:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

  [Regression Potential]

   * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
     (published to mantic-updates on 2023-12-08) _and_ enabled the
     option (with typo) would have such functionality disabled.

  [Other Info]

   * This option (with typo) was introduced in commit d19304ffeec5
     ("zed: Add zedlet to power off slot when drive is faulted"),
     and is present in:
     - ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
     - ZFS 2.1: zfs-2.1.13

   * It affects Ubuntu Noble and Mantic, but not Lunar or older.

   * Fixed upstream with commit 3c7650491b9a ("zed: fix typo in 
 variable ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2046082/+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

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Started the work to merge crash 8.0.4 in bug 2047861.

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  In Progress
Status in crash source package in Jammy:
  Incomplete
Status in crash source package in Lunar:
  Incomplete
Status in crash source package in Mantic:
  Incomplete

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "aarch64-unknown-linux-gnu".
  Type "show configuration" for configuration details.
  Find the GDB manual and other documentation resources online at:
  

[Kernel-packages] [Bug 2047861] Re: Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

Merge is in git branch
https://code.launchpad.net/~mfo/ubuntu/+source/crash/+git/crash/+ref/merge-lp2047861-noble

Building/testing from PPA
https://launchpad.net/~mfo/+archive/ubuntu/lp2047861-noble-crash

Still in progress.

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

Title:
   Merge crash 8.0.4-1 into Noble

Status in crash package in Ubuntu:
  In Progress

Bug description:
  $ rmadison -a source crash | grep noble
   crash | 8.0.3+ds1-3ubuntu1 | noble  | source

  $ rmadison -a source -u debian -s unstable crash
  crash  | 8.0.4-1   | unstable   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2047861/+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

[Kernel-packages] [Bug 2047861] Re: Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

Work in progress.

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

Title:
   Merge crash 8.0.4-1 into Noble

Status in crash package in Ubuntu:
  In Progress

Bug description:
  $ rmadison -a source crash | grep noble
   crash | 8.0.3+ds1-3ubuntu1 | noble  | source

  $ rmadison -a source -u debian -s unstable crash
  crash  | 8.0.4-1   | unstable   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2047861/+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

[Kernel-packages] [Bug 2047861] [NEW] Merge crash 8.0.4-1 into Noble

[Mauricio Faria de Oliveira]

Public bug reported:

$ rmadison -a source crash | grep noble
 crash | 8.0.3+ds1-3ubuntu1 | noble  | source

$ rmadison -a source -u debian -s unstable crash
crash  | 8.0.4-1   | unstable   | source

** Affects: crash (Ubuntu)
 Importance: Medium
 Assignee: Mauricio Faria de Oliveira (mfo)
 Status: In Progress

** Changed in: crash (Ubuntu)
   Status: New => In Progress

** Changed in: crash (Ubuntu)
   Importance: Undecided => Medium

** Changed in: crash (Ubuntu)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

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

Title:
   Merge crash 8.0.4-1 into Noble

Status in crash package in Ubuntu:
  In Progress

Bug description:
  $ rmadison -a source crash | grep noble
   crash | 8.0.3+ds1-3ubuntu1 | noble  | source

  $ rmadison -a source -u debian -s unstable crash
  crash  | 8.0.4-1   | unstable   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2047861/+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

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

-crash-mantic.debdiff | sed 's,.*/,,' | while read 
commit; do echo -n "COMMIT $commit is in "; GIT_DIR=~/git/crash/.git git 
describe --contains $commit; done
COMMIT 222176a0a6c14b6a1cdcebb8dda020ccb17b90f8 is in 8.0.3~24
COMMIT 46344aa2f92b07ded52cf9841f8db24dd7fe67d7 is in 8.0.3~21
COMMIT d17d51a92a3a1c1cce1e646c38fe52ca99406cf9 is in 8.0.4~26
COMMIT 55a43bcefa20161c7e56ed0e309e90e941f47efc is in 8.0.4~2
COMMIT 4ee56105881d7bb1da1e668ac5bb47a4e0846676 is in 8.0.4~29
COMMIT 58c1816521c2e6bece3d69256b1866c9df8d93aa is in 8.0.4~42
COMMIT 88580068b7dd96bf679c82bdc05e146968ade10c is in 8.0.4~30
COMMIT 41d4b85ea50efc733df65ec8421a74be10e47987 is in 8.0.3~31
COMMIT f182d08bab202dddf20b742fef6cc2bda0a56d6c is in 8.0.3~43
COMMIT 6d0be1316aa3666895c0a8a0d3c98c235ec03bd4 is in 8.0.4~28
COMMIT 38d35bd1423ccafd0b8be0744155ce59ef3034ff is in 8.0.4~25
COMMIT 489093c2183f4f0365d8957e7275cd88225942ce is in 8.0.3~8
COMMIT 342cf340ed0386880fe2a3115d6bef32eabb511b is in 8.0.4~41
COMMIT 0172e35083b545fa7dd640fa5de0111f8474fc14 is in 8.0.4~5
COMMIT 9efc1f68a44f6fe521e64efe4a3dc36e9ba0bbc1 is in 8.0.3~23
COMMIT 872cad2d63b3a07f65323fe80a7abb29ea276b44 is in 8.0.3~26
COMMIT 120d6e89fc14eb7f1c9a3106305c7066730f36b8 is in 8.0.3~28
COMMIT ac96e17d1de51016ee1a983e68c7e840ff55ab8d is in 8.0.3~27
COMMIT d83df2fb66cd77877d365fda32cd45c531796599 is in 8.0.3~32
COMMIT 7750e61fdb2a083f26156a5338aa2ebe26447f3f is in 8.0.4~31
COMMIT c9a732d0f6abe8c63f19fee5233544633dfd309f is in 8.0.4~11
COMMIT 141e75f3c11cc9342f11418e0bec86877424bef8 is in 8.0.3~46
COMMIT 77d8621876c1c6a3a25b91e464ba588a542485fb is in 8.0.4~36
COMMIT df1f0cba729fa0e0d8a63220769c42cc9033acc1 is in 8.0.3~44

$ grep 'Origin: ' lp2038249-crash-mantic.debdiff | sed 's,.*/,,' | while read 
commit; do echo -n "COMMIT $commit is in "; GIT_DIR=~/git/crash/.git git 
describe --contains $commit; done | grep -c 8.0.4
12

[4]
https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging

** Changed in: crash (Ubuntu Mantic)
   Status: In Progress => Incomplete

** Changed in: crash (Ubuntu Lunar)
   Status: In Progress => Incomplete

** Changed in: crash (Ubuntu Jammy)
   Status: In Progress => Incomplete

** Changed in: crash (Ubuntu)
 Assignee: Chengen Du (chengendu) => Mauricio Faria de Oliveira (mfo)

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  In Progress
Status in crash source package in Jammy:
  Incomplete
Status in crash source package in Lunar:
  Incomplete
Status in crash source package in Mantic:
  Incomplete

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr:

[Kernel-packages] [Bug 2046082] Re: zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

[Mauricio Faria de Oliveira]

I will stage this to mantic with an upload + block-proposed-mantic tag.

The mantic unapproved queue already has zfs-linux 2.2.2-0ubuntu1~23.10,
but it seems it is not going to be accepted per bug 2044657 comment 46.

If that bug gets cherry-pick fixes as requested, that should be simple
to combine with the staged upload. Or if the full upstream backport to
2.2.2 (from 2.2.0) is accepted there, I am happy to re-upload with it.

Attaching the debdiff for reference.

** Patch added: "lp2046082_zfs-linux_mantic_2.2.0.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2046082/+attachment/5728907/+files/lp2046082_zfs-linux_mantic_2.2.0.debdiff

** Tags added: block-proposed-mantic

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

Title:
  zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Mantic:
  Confirmed
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [Impact]

   * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
     ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
     in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.

   * This could be fixed in Ubuntu before users start adopting it.

  [Test Plan]

   * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.

   * Actual:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

   * Expected:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

  [Regression Potential]

   * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
     (published to mantic-updates on 2023-12-08) _and_ enabled the
     option (with typo) would have such functionality disabled.

  [Other Info]

   * This option (with typo) was introduced in commit d19304ffeec5
     ("zed: Add zedlet to power off slot when drive is faulted"),
     and is present in:
     - ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
     - ZFS 2.1: zfs-2.1.13

   * It affects Ubuntu Noble and Mantic, but not Lunar or older.

   * Fixed upstream with commit 3c7650491b9a ("zed: fix typo in 
 variable ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2046082/+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

[Kernel-packages] [Bug 2046082] Re: zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

[Mauricio Faria de Oliveira]

Testing for Mantic:

mantic-updates:

$ rmadison -a source zfs-linux -s mantic-updates
 zfs-linux | 2.2.0-0ubuntu1~23.10 | mantic-updates | source

$ dpkg -s zfs-zed | grep Version:
Version: 2.2.0-0ubuntu1~23.10

$ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
#ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

$ dpkg -L zfs-zed | xargs grep ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT 
2>/dev/null | sort
/etc/zfs/zed.d/zed.rc:#ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1
/usr/lib/zfs-linux/zed.d/statechange-slot_off.sh:#   2: 
ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT disabled
/usr/lib/zfs-linux/zed.d/statechange-slot_off.sh:# 
ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT is set in zed.rc, and the disk gets
/usr/lib/zfs-linux/zed.d/statechange-slot_off.sh:if [ 
"${ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT}" != "1" ] ; then

test package:

$ dpkg-deb -x zfs-zed_2.2.0-0ubuntu1~23.10.1_amd64.deb deb

$ grep ZED_POWER_OFF_ENCLO deb/etc/zfs/zed.d/zed.rc
#ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

- wrong name (no matches anymore):

$ find deb | xargs grep ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT 
2>/dev/null
$

- right name (all matches fixed):

$ find deb | xargs grep ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT 
2>/dev/null | sort
deb/etc/zfs/zed.d/zed.rc:#ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1
deb/usr/lib/zfs-linux/zed.d/statechange-slot_off.sh:#   2: 
ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT disabled
deb/usr/lib/zfs-linux/zed.d/statechange-slot_off.sh:# 
ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT is set in zed.rc, and the disk gets
deb/usr/lib/zfs-linux/zed.d/statechange-slot_off.sh:if [ 
"${ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT}" != "1" ] ; then

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

Title:
  zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Mantic:
  Confirmed
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [Impact]

   * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
     ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
     in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.

   * This could be fixed in Ubuntu before users start adopting it.

  [Test Plan]

   * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.

   * Actual:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

   * Expected:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

  [Regression Potential]

   * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
     (published to mantic-updates on 2023-12-08) _and_ enabled the
     option (with typo) would have such functionality disabled.

  [Other Info]

   * This option (with typo) was introduced in commit d19304ffeec5
     ("zed: Add zedlet to power off slot when drive is faulted"),
     and is present in:
     - ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
     - ZFS 2.1: zfs-2.1.13

   * It affects Ubuntu Noble and Mantic, but not Lunar or older.

   * Fixed upstream with commit 3c7650491b9a ("zed: fix typo in 
 variable ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2046082/+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

[Kernel-packages] [Bug 2046082] Re: zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

[Mauricio Faria de Oliveira]

noble:

$ dpkg -s zfs-zed | grep Version:
Version: 2.2.2-0ubuntu1

$ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
#ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

test package:

$ dpkg-deb -x zfs-zed_2.2.2-0ubuntu2_amd64.deb deb

$ grep ZED_POWER_OFF_ENCLO deb/etc/zfs/zed.d/zed.rc
#ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1


** Patch added: "lp2046082_zfs-linux_noble.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2046082/+attachment/5728045/+files/lp2046082_zfs-linux_noble.debdiff

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

Title:
  zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

Status in zfs-linux package in Ubuntu:
  Confirmed
Status in zfs-linux source package in Mantic:
  Confirmed
Status in zfs-linux source package in Noble:
  Confirmed

Bug description:
  [Impact]

   * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
     ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
     in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.

   * This could be fixed in Ubuntu before users start adopting it.

  [Test Plan]

   * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.

   * Actual:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

   * Expected:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

  [Regression Potential]

   * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
     (published to mantic-updates on 2023-12-08) _and_ enabled the
     option (with typo) would have such functionality disabled.

  [Other Info]

   * This option (with typo) was introduced in commit d19304ffeec5
     ("zed: Add zedlet to power off slot when drive is faulted"),
     and is present in:
     - ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
     - ZFS 2.1: zfs-2.1.13

   * It affects Ubuntu Noble and Mantic, but not Lunar or older.

   * Fixed upstream with commit 3c7650491b9a ("zed: fix typo in 
 variable ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2046082/+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

[Kernel-packages] [Bug 2046082] Re: zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

[Mauricio Faria de Oliveira]

Subscribing ~ubuntu-sponsors for review/sponsoring to Noble.
(I can handle the upload to mantic later.)

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

Title:
  zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

Status in zfs-linux package in Ubuntu:
  Confirmed
Status in zfs-linux source package in Mantic:
  Confirmed
Status in zfs-linux source package in Noble:
  Confirmed

Bug description:
  [Impact]

   * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
     ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
     in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.

   * This could be fixed in Ubuntu before users start adopting it.

  [Test Plan]

   * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.

   * Actual:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

   * Expected:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

  [Regression Potential]

   * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
     (published to mantic-updates on 2023-12-08) _and_ enabled the
     option (with typo) would have such functionality disabled.

  [Other Info]

   * This option (with typo) was introduced in commit d19304ffeec5
     ("zed: Add zedlet to power off slot when drive is faulted"),
     and is present in:
     - ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
     - ZFS 2.1: zfs-2.1.13

   * It affects Ubuntu Noble and Mantic, but not Lunar or older.

   * Fixed upstream with commit 3c7650491b9a ("zed: fix typo in 
 variable ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2046082/+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

[Kernel-packages] [Bug 2046082] Re: zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

[Mauricio Faria de Oliveira]

Ubuntu:

$ rmadison -a source zfs-linux
...
 zfs-linux | 0.8.3-1ubuntu12| focal   | source
 zfs-linux | 0.8.3-1ubuntu12.16 | focal-security  | source
 zfs-linux | 0.8.3-1ubuntu12.16 | focal-updates   | source
 zfs-linux | 2.1.2-1ubuntu3 | jammy   | source
 zfs-linux | 2.1.5-1ubuntu6~22.04.2 | jammy-security  | source
 zfs-linux | 2.1.5-1ubuntu6~22.04.2 | jammy-updates   | source
 zfs-linux | 2.1.9-2ubuntu1 | lunar   | source
 zfs-linux | 2.1.9-2ubuntu1.2   | lunar-security  | source
 zfs-linux | 2.1.9-2ubuntu1.2   | lunar-updates   | source
 zfs-linux | 2.2.0~rc3-0ubuntu4 | mantic  | source
 zfs-linux | 2.2.0-0ubuntu1~23.10   | mantic-proposed | source
 zfs-linux | 2.2.0-0ubuntu1~23.10   | mantic-updates  | source
 zfs-linux | 2.2.2-0ubuntu1 | noble   | source

$ git show pkg/ubuntu/focal-devel:./cmd/zed/zed.d/zed.rc | grep 
ZED_POWER_OFF_ENCLO
$ git show pkg/ubuntu/jammy-devel:./cmd/zed/zed.d/zed.rc | grep 
ZED_POWER_OFF_ENCLO
$ git show pkg/ubuntu/lunar-devel:./cmd/zed/zed.d/zed.rc | grep 
ZED_POWER_OFF_ENCLO

$ git show pkg/ubuntu/mantic-devel:./cmd/zed/zed.d/zed.rc | grep 
ZED_POWER_OFF_ENCLO
#ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

$ git show pkg/ubuntu/noble-devel:./cmd/zed/zed.d/zed.rc | grep 
ZED_POWER_OFF_ENCLO
#ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1


** Description changed:

  [Impact]
  
-  * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
-ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
-in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.
+  * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
+    ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
+    in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.
  
-  * This could be fixed in Ubuntu before users start adopting it.
+  * This could be fixed in Ubuntu before users start adopting it.
  
  [Test Plan]
  
-  * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.
+  * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.
  
-  * Actual:
-$ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
-#ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1
+  * Actual:
+    $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
+    #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1
  
-  * Expected:
-$ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
-#ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1
+  * Expected:
+    $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
+    #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1
  
  [Regression Potential]
  
-  * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
-(published to mantic-updates on 2023-12-08) _and_ enabled the
-option (with typo) would have such functionality disabled.
+  * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
+    (published to mantic-updates on 2023-12-08) _and_ enabled the
+    option (with typo) would have such functionality disabled.
  
  [Other Info]
  
-  * This option (with typo) was introduced in commit d19304ffeec5
-("zed: Add zedlet to power off slot when drive is faulted"),
-and is present in:
-- ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
-- ZFS 2.1: zfs-2.1.13
+  * This option (with typo) was introduced in commit d19304ffeec5
+    ("zed: Add zedlet to power off slot when drive is faulted"),
+    and is present in:
+    - ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
+    - ZFS 2.1: zfs-2.1.13
  
-  * It affects Ubuntu Noble and Mantic, but not Lunar or older.
+  * It affects Ubuntu Noble and Mantic, but not Lunar or older.
+ 
+  * Fixed upstream with commit 3c7650491b9a ("zed: fix typo in 
+variable ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT")

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

Title:
  zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

Status in zfs-linux package in Ubuntu:
  Confirmed
Status in zfs-linux source package in Mantic:
  Confirmed
Status in zfs-linux source package in Noble:
  Confirmed

Bug description:
  [Impact]

   * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
     ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
     in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.

   * This could be fixed in Ubuntu before users start adopting it.

  [Test Plan]

   * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.

   * Actual:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

   * Expected:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

  [Regression Potential]

   * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
     (published to mantic-updates on 2023-12-08) _and_ enabled the
     option (with typo) would have such functionality disabled.

  [Other Info]

   * 

[Kernel-packages] [Bug 2046082] Re: zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

[Mauricio Faria de Oliveira]

Upstream:

$ git log --oneline origin/zfs-2.2-release -- cmd/zed/zed.d/zed.rc | grep 'zed: 
Add zedlet to power off slot when drive is faulted'
d19304ffeec5 zed: Add zedlet to power off slot when drive is faulted
$ git describe --contains d19304ffeec5
zfs-2.2.0-rc4~14

$ git log --oneline origin/zfs-2.1-release -- cmd/zed/zed.d/zed.rc | grep 'zed: 
Add zedlet to power off slot when drive is faulted'
a4f82db53d6d zed: Add zedlet to power off slot when drive is faulted
$ git describe --contains a4f82db53d6d
zfs-2.1.13~6

$ git log --oneline origin/zfs-2.0-release -- cmd/zed/zed.d/zed.rc | grep 'zed: 
Add zedlet to power off slot when drive is faulted'
$

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

Title:
  zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

Status in zfs-linux package in Ubuntu:
  Confirmed
Status in zfs-linux source package in Mantic:
  Confirmed
Status in zfs-linux source package in Noble:
  Confirmed

Bug description:
  [Impact]

   * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
     ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
     in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.

   * This could be fixed in Ubuntu before users start adopting it.

  [Test Plan]

   * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.

   * Actual:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

   * Expected:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

  [Regression Potential]

   * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
     (published to mantic-updates on 2023-12-08) _and_ enabled the
     option (with typo) would have such functionality disabled.

  [Other Info]

   * This option (with typo) was introduced in commit d19304ffeec5
     ("zed: Add zedlet to power off slot when drive is faulted"),
     and is present in:
     - ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
     - ZFS 2.1: zfs-2.1.13

   * It affects Ubuntu Noble and Mantic, but not Lunar or older.

   * Fixed upstream with commit 3c7650491b9a ("zed: fix typo in 
 variable ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2046082/+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

[Kernel-packages] [Bug 2046082] [NEW] zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

[Mauricio Faria de Oliveira]

Public bug reported:

[Impact]

 * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
   ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
   in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.

 * This could be fixed in Ubuntu before users start adopting it.

[Test Plan]

 * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.

 * Actual:
   $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
   #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

 * Expected:
   $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
   #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

[Regression Potential]

 * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
   (published to mantic-updates on 2023-12-08) _and_ enabled the
   option (with typo) would have such functionality disabled.

[Other Info]

 * This option (with typo) was introduced in commit d19304ffeec5
   ("zed: Add zedlet to power off slot when drive is faulted"),
   and is present in:
   - ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
   - ZFS 2.1: zfs-2.1.13

 * It affects Ubuntu Noble and Mantic, but not Lunar or older.

 * Fixed upstream with commit 3c7650491b9a ("zed: fix typo in 
   variable ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT")

** Affects: zfs-linux (Ubuntu)
 Importance: Medium
     Assignee: Mauricio Faria de Oliveira (mfo)
 Status: Confirmed

** Affects: zfs-linux (Ubuntu Mantic)
 Importance: Medium
     Assignee: Mauricio Faria de Oliveira (mfo)
 Status: Confirmed

** Affects: zfs-linux (Ubuntu Noble)
 Importance: Medium
     Assignee: Mauricio Faria de Oliveira (mfo)
 Status: Confirmed

** Changed in: zfs-linux (Ubuntu)
   Status: New => Confirmed

** Also affects: zfs-linux (Ubuntu Mantic)
   Importance: Undecided
   Status: New

** Also affects: zfs-linux (Ubuntu Noble)
   Importance: Undecided
   Status: Confirmed

** Changed in: zfs-linux (Ubuntu Mantic)
   Importance: Undecided => Medium

** Changed in: zfs-linux (Ubuntu Noble)
   Importance: Undecided => Medium

** Changed in: zfs-linux (Ubuntu Mantic)
   Status: New => Confirmed

** Changed in: zfs-linux (Ubuntu Mantic)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: zfs-linux (Ubuntu Noble)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

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

Title:
  zed.rc: typo in option ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT

Status in zfs-linux package in Ubuntu:
  Confirmed
Status in zfs-linux source package in Mantic:
  Confirmed
Status in zfs-linux source package in Noble:
  Confirmed

Bug description:
  [Impact]

   * There's a typo in user-visible option (/etc/zfs/zed.d/zed.rc)
     ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT introduced upstream
     in 2.2.0-rc4 and SRU-ed to Mantic with 2.2.0-0ubuntu1~23.10.

   * This could be fixed in Ubuntu before users start adopting it.

  [Test Plan]

   * Check whether /etc/zfs/zed.d/zed.rc ships the correct option.

   * Actual:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT=1

   * Expected:
     $ grep ZED_POWER_OFF_ENCLO /etc/zfs/zed.d/zed.rc
     #ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT=1

  [Regression Potential]

   * Users of Mantic who upgraded to zfs-linux 2.2.0-0ubuntu1~23.10
     (published to mantic-updates on 2023-12-08) _and_ enabled the
     option (with typo) would have such functionality disabled.

  [Other Info]

   * This option (with typo) was introduced in commit d19304ffeec5
     ("zed: Add zedlet to power off slot when drive is faulted"),
     and is present in:
     - ZFS 2.2: zfs-2.2.0-rc4 (mantic-updates)
     - ZFS 2.1: zfs-2.1.13

   * It affects Ubuntu Noble and Mantic, but not Lunar or older.

   * Fixed upstream with commit 3c7650491b9a ("zed: fix typo in 
 variable ZED_POWER_OFF_ENCLO*US*RE_SLOT_ON_FAULT")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2046082/+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

[Kernel-packages] [Bug 2040181] Re: upgrade zfs-linux to 2.2.0 final

[Mauricio Faria de Oliveira]

Hi Dimitri,

Thanks for the details of the test plan execution!

That covers the kernel module/filesystem code quite well, thanks,
and there's the userspace tooling changes left, as you mentioned.

> In practice this SRU is already released to most users via LXD and via kernel 
> upgrades. 
> The change this sru release will introduce is userspace tooling update, which 
> was minor in this update.

I looked up the changes to userspace commands (in subdir `zfs/cmd/`),
and would agree they are (mostly) minor, with a few notes to have
documented (and for others to review), but IMHO, none are blocking
for the release of this SRU.

cheers,
Mauricio

Related commits:

$ git log --oneline zfs-2.2.0-rc3..zfs-2.2.0 -- cmd/
33d7c2d165c2 import: require force when cachefile hostid doesn't match 
on-disk
8015e2ea66b4 Add '-u' - nomount flag for zfs set
c53bc3837cb6 Improve the handling of sharesmb,sharenfs properties
e9dc31c74e7b Update the behavior of mountpoint property
608741d062fe Report ashift of L2ARC devices in zdb
0ce1b2ca1930 Invoke zdb by guid to avoid import errors
0aabd6b48228 ZIL: Avoid dbuf_read() in ztest_get_data()
3af63683fe07 cmd: add 'help' subcommand to zpool and zfs
9aa1a2878ea9 Fix incorrect expected error in ztest
54c6fbd378ea zed: Allow autoreplace and fault LEDs for removed vdevs
32949f2560bf Relax error reporting in zpool import and zpool split
63159e5bda1c checkstyle: fix action failures
e99e684b337b zed: update zed.d/statechange-slot_off.sh
d19304ffeec5 zed: Add zedlet to power off slot when drive is faulted
df8c9f351dab ZIL: Second attempt to reduce scope of zl_issuer_lock.
12f2b1f65e91 zdb: include cloned blocks in block statistics

Spotted changes/commits:

1) Config option with typo

commit d19304ffeec50ebc02cf4496c14e8945c74fb76a
Author: Tony Hutter 
Date:   Thu Aug 24 11:59:03 2023 -0700

zed: Add zedlet to power off slot when drive is faulted

If ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT is enabled in zed.rc, then
power off the drive's slot in the enclosure if it becomes FAULTED.
This can help silence misbehaving drives.  This assumes your drive
enclosure fully supports slot power control via sysfs.

This new option is disabled by default, good.
However, the option has a typo, so I submitted patch [1] upstream,
and it would be nice if we pick it up later on.

[1] https://github.com/openzfs/zfs/pull/15651

...

2) zpool import/split no longer reflect errors to mount/share

commit 32949f2560bf35ec86dfa5d984514908e0eb3ecc
Author: Umer Saleem 
Date:   Sat Sep 2 05:25:11 2023 +0500

Relax error reporting in zpool import and zpool split

For zpool import and zpool split, zpool_enable_datasets is called
to mount and share all datasets in a pool. If there is an error
while mounting or sharing any dataset in the pool, the status of
import or split is reported as failure. However, the changes do
show up in zpool list.

This commit updates the error reporting in zpool import and zpool
split path. More descriptive messages are shown to user in case
there is an error during mount or share. Errors in mount or share
do not effect the overall status of zpool import and zpool split.

...

3) zed can now autoreplace vdevs marked as REMOVED

This change is effective by default, since zed/config option are.

commit 54c6fbd378eaa402eff34acf6a91c02d6cf9da11
Author: Tony Hutter 
Date:   Mon Sep 18 16:25:58 2023 -0700

zed: Allow autoreplace and fault LEDs for removed vdevs

Allow zed to autoreplace vdevs marked as REMOVED.  Also update
statechange-led zedlet to toggle fault LEDs for REMOVED vdevs.

Reviewed-by: Brian Behlendorf 
Signed-off-by: Tony Hutter 
Closes #15281

See,

$ git show 
54c6fbd378eaa402eff34acf6a91c02d6cf9da11:cmd/zed/zed.d/statechange-led.sh | 
grep 'if .*ZED'
if [ "${ZED_USE_ENCLOSURE_LEDS}" != "1" ] ; then

$ sudo apt update && sudo apt install -y zfsutils-linux

$ systemctl status zfs-zed.service | grep Active:
 Active: active (running) ...

$ grep ZED_USE_ENCLOSURE_LEDS /etc/zfs/zed.d/zed.rc
ZED_USE_ENCLOSURE_LEDS=1

...

4) Changes to mountpoint property handling / remounting

This is a behavior change, but it looks like a good/consistent one,
adopted by upstream between RC and Release time, so it seems worse
to diverge from upstream when we do a similar RC to Release update.

And in case of impact to particular users/scripts/scenarios, there
is a new option to fall back to previous behavior.

commit e9dc31c74e7b28a0cb2a321bc220074f6461d231
Author: Umer Saleem 
Date:   Tue Sep 5 13:27:53 2023 +0500

Update the behavior of mountpoint property

...

To make the behavior consistent in case dataset is mounted or
unmounted, we should try to mount the dataset whenever mountpoint
property is updated. This would result in 

[Kernel-packages] [Bug 2040181] Re: upgrade zfs-linux to 2.2.0 final

[Mauricio Faria de Oliveira]

Hi Dimitri,

Could you please provide more evidence/details of the test plan
execution, considering this SRU is related to a filesystem?

```
[ Test Plan ]

 * autopkgtest pass

 * kernel regression zfs testsuite pass

 * zsys integration test pass

 * LXD support retested
```

The autopkgtests are OK [1], but the remaining items aren't documented.

[1] https://ubuntu-archive-team.ubuntu.com/proposed-
migration/mantic/update_excuses.html#zfs-linux

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

Title:
  upgrade zfs-linux to 2.2.0 final

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Mantic:
  Fix Committed
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [ Impact ]

   * Potential data loss with zfs 2.2.0-rc3 resolved in -rc5, proposal
  to update to final

   * Ubuntu Mantic shipped 2.2.0-rc3 with approximately 10 additional
  cherrypicks, or kernel team created fixes that got contributed &
  accepted upstream. At the time this was the only way to get zfs
  working with  v6.5 kernels and also drop the need for shiftfs (due to
  zfs impovements). Since us shipping this package, upstream has
  identified and fixed multiple small bugfixes in the subsequent RC and
  the final releases, including one bug fix that can lead to potential
  data loss.

   * The 2.2.0 release branch was frozen for a long time already, and
  outstanding number of commits of fixes that Mantic does not have is
  less than 30 small patches.

   * Proposal to upgrade our build to 2.2.0 final, pick up all the
  regression fixes, and drop all the cherrypicked patches that enable
  v6.5 support. This will give us the best kernel driver to support in
  the runnup to next Ubuntu LTS.

  [ Test Plan ]

   * autopkgtest pass

   * kernel regression zfs testsuite pass

   * zsys integration test pass

   * LXD support retested

  [ Where problems could occur ]

   * LXD snap in edge shipped zfs tooling of RC5 version until 16th
  October when they upgraded to 2.2.0 final, there are no kernel-
  userspace incompatiblities between RC & final, but we should
  explicitly test this.

  [ Other Info ]

   * Upstream is alerting us to the potential data loss and requesting
  upgrade to 2.2.0-rc5 or better.

  [ Abbriviated changes being introduced ]

  $ git log --oneline 4a104ac047..95785196f2 -- cmd/ lib/ module/os/linux/ | 
grep -v compat
  810fc49a3e Ensure we call fput when cloning fails due to different devices.
  a80e1f1c90 zvol: Temporally disable blk-mq
  33d7c2d165 import: require force when cachefile hostid doesn't match on-disk
  8015e2ea66 Add '-u' - nomount flag for zfs set
  c53bc3837c Improve the handling of sharesmb,sharenfs properties
  e9dc31c74e Update the behavior of mountpoint property
  608741d062 Report ashift of L2ARC devices in zdb
  0ce1b2ca19 Invoke zdb by guid to avoid import errors
  0aabd6b482 ZIL: Avoid dbuf_read() in ztest_get_data()
  a199cac6cd status: report pool suspension state under failmode=continue
  729507d309 Fix occasional rsend test crashes
  3af63683fe cmd: add 'help' subcommand to zpool and zfs
  9aa1a2878e Fix incorrect expected error in ztest
  f7a07d76ee Retire z_nr_znodes
  54c6fbd378 zed: Allow autoreplace and fault LEDs for removed vdevs
  32949f2560 Relax error reporting in zpool import and zpool split
  63159e5bda checkstyle: fix action failures
  e99e684b33 zed: update zed.d/statechange-slot_off.sh
  d19304ffee zed: Add zedlet to power off slot when drive is faulted
  92f095a903 copy_file_range: fix fallback when source create on same txg
  895cb689d3 zfs_clone_range should return a descriptive error codes
  6bdc7259d1 libzfs: sendrecv: send_progress_thread: handle SIGINFO/SIGUSR1
  df8c9f351d ZIL: Second attempt to reduce scope of zl_issuer_lock.
  0ae7bfc0a4 zpool_vdev_remove() should handle EALREADY error return
  bd1eab16eb linux: zfs: ctldir: set [amc]time to snapshot's creation property
  c47f0f4417 linux/copy_file_range: properly request a fallback copy on Linux 
<5.3
  12f2b1f65e zdb: include cloned blocks in block statistics

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2040181/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

** Merge proposal linked:
   https://code.launchpad.net/~mfo/ubuntu/+source/crash/+git/crash/+merge/455464

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Merge Request / git-ubuntu:

  https://code.launchpad.net/~mfo/ubuntu/+source/crash/+git/crash/+merge/455353

  Test packages:

  ppa:mfo/noble-crash-v2

  ...

  Versions:

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source

  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source

  ...

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

  ...

  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

** Merge proposal linked:
   https://code.launchpad.net/~mfo/ubuntu/+source/crash/+git/crash/+merge/455353

** Description changed:

- Work in progress; rebasing on 8.0.3+ds1-3, and testing.
+ Merge Request / git-ubuntu:
+ 
+ https://code.launchpad.net/~mfo/ubuntu/+source/crash/+git/crash/+merge/455353
  
  ...
+ 
+ Versions:
  
  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source
  
  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source
  
  ...
  
  Debian bugs:
  
  https://bugs.debian.org/1054805
  Please update crash to 8.0.3
  
  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz
  
  ...
  
  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

** Description changed:

  Merge Request / git-ubuntu:
  
  https://code.launchpad.net/~mfo/ubuntu/+source/crash/+git/crash/+merge/455353
+ 
+ Test packages:
+ 
+ ppa:mfo/noble-crash-v2
  
  ...
  
  Versions:
  
  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source
  
  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source
  
  ...
  
  Debian bugs:
  
  https://bugs.debian.org/1054805
  Please update crash to 8.0.3
  
  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz
  
  ...
  
  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Merge Request / git-ubuntu:

  https://code.launchpad.net/~mfo/ubuntu/+source/crash/+git/crash/+merge/455353

  Test packages:

  ppa:mfo/noble-crash-v2

  ...

  Versions:

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source

  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source

  ...

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

  ...

  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

amd64
-

vm

lxc launch --vm -c limits.cpu=2 -c limits.memory=2GiB 
ubuntu-daily:noble noble-vm
lxc shell noble-vm

# uname -rv
6.5.0-9-generic #9-Ubuntu SMP PREEMPT_DYNAMIC Sat Oct  7 01:35:40 UTC 
2023


kdump-tools

sudo apt update && apt install -y linux-crashdump # No, Yes
sudo sed 's/crashkernel=[^" ]\+/crashkernel=512M/' -i 
/etc/default/grub.d/kdump-tools.cfg
sudo update-grub && sudo reboot

...

# dmesg | grep 'crashkernel.*RAM'
[0.018756] Reserving 512MB of memory at 816MB for crashkernel 
(System RAM: 2043MB)

# kdump-config status
current state   : ready to kdump

crashdump

# echo c >/proc/sysrq-trigger

...

# find /var/crash/
/var/crash/
/var/crash/kdump_lock
/var/crash/kexec_cmd
/var/crash/202311081257
/var/crash/202311081257/dmesg.202311081257
/var/crash/202311081257/dump.202311081257
/var/crash/linux-image-6.5.0-9-generic-202311081257.crash

debug symbols

dpkg -l | awk '$2 ~ /linux-image-[0-9.-]+-generic/ { print $2, $3}' \
  | while read pkg version; do \
  dbgpkg="linux-image-unsigned-${pkg#linux-image-}-dbgsym"; \
  arch=$(dpkg --print-architecture); \
  wget 
"https://launchpad.net/ubuntu/+archive/primary/+files/${dbgpkg}_${version}_${arch}.ddeb;;
 \
done

ar p linux-image-unsigned-*-dbgsym_*.ddeb data.tar.xz | tar xJ
--wildcards './usr/lib/debug/boot/vmlinux-*-generic'

crash (old)

# dpkg -s crash | grep Version:
Version: 8.0.2-1ubuntu1

# crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
crash: invalid structure member offset: module_core_size
   FILE: kernel.c  LINE: 3781  FUNCTION: module_init()

[/usr/bin/crash] error trace: 558bf515829f => 558bf4dd7efc =>
558bf4e64bff => 558bf4eef301

crash (new)

sudo add-apt-repository -y ppa:mfo/noble-crash-v2 && sudo apt
install -y crash

# crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
please wait... (determining panic task)
WARNING: active task 93c084ed on cpu 0 not found in PID hash

  KERNEL: ./usr/lib/debug/boot/vmlinux-6.5.0-9-generic
DUMPFILE: /var/crash/202311081257/dump.202311081257  [PARTIAL DUMP]
CPUS: 2
DATE: Wed Nov  8 12:57:51 UTC 2023
  UPTIME: 00:01:42
LOAD AVERAGE: 0.28, 0.18, 0.07
   TASKS: 3
NODENAME: noble-vm
 RELEASE: 6.5.0-9-generic
 VERSION: #9-Ubuntu SMP PREEMPT_DYNAMIC Sat Oct  7 01:35:40 UTC 2023
 MACHINE: x86_64  (2495 Mhz)
  MEMORY: 2 GB
   PANIC: "Kernel panic - not syncing: sysrq triggered crash"
 PID: 4488
 COMMAND: "bash"
TASK: 93c084ed  [THREAD_INFO: 93c084ed]
 CPU: 0
   STATE: TASK_RUNNING (PANIC)

crash> bt
PID: 4488 TASK: 93c084ed  CPU: 0COMMAND: "bash"
 #0 [a9c500d0bb38] machine_kexec at 9dcafa3b
 #1 [a9c500d0bb98] __crash_kexec at 9de133f3
 #2 [a9c500d0bc60] panic at 9dcf60e4
 #3 [a9c500d0bce0] sysrq_handle_crash at 9e6a4b5a
 #4 [a9c500d0bcf0] __handle_sysrq at 9e6a52e3
 #5 [a9c500d0bd38] write_sysrq_trigger at 9e6a5b28
 #6 [a9c500d0bd50] proc_reg_write at 9e1691b9
 #7 [a9c500d0bd70] vfs_write at 9e0af87f
 #8 [a9c500d0be10] ksys_write at 9e0aff83
 #9 [a9c500d0be50] __x64_sys_write at 9e0b0039
#10 [a9c500d0be60] do_syscall_64 at 9ed399a9
#11 [a9c500d0bf50] entry_SYSCALL_64_after_hwframe at 
9ee000e6
RIP: 7fd7ba71b214  RSP: 7ffd1900fbc8  RFLAGS: 0202
RAX: ffda  RBX: 0002  RCX: 7fd7ba71b214
RDX: 0002  RSI: 55b4326b7d60  RDI: 0001
RBP: 55b4326b7d60   R8: 0073   R9: 
R10:   R11: 0202  R12: 0002
R13: 7fd7ba7ff7a0  R14: 7fd7ba7fd120  R15: 
ORIG_RAX: 0001  CS: 0033  SS: 002b
crash> quit

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  ...

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

armhf 
(fails to kexec to the crash kernel, anyway, for doc purposes)
-

vm

sudo modprobe nbd
sudo qemu-nbd -c /dev/nbd0 noble-server-cloudimg-armhf.img
mkdir mnt
sudo mount /dev/nbd0p16 mnt

sudo cp mnt/vmlinuz-*-generic mnt/initrd.img-*-generic .
sudo chown $USER vmlinuz-*-generic initrd.img-*-generic

sudo umount mnt
sudo qemu-nbd -d /dev/nbd0
sudo modprobe -r nbd

qemu-system-arm \
-machine virt -cpu cortex-a15 \
\
-kernel vmlinuz-*-generic \
-initrd initrd.img-*-generic \
-append 'root=LABEL=cloudimg-rootfs crashkernel=512M' \
\
-smp cpus=2 -m 2048 \
-nodefaults -no-user-config \
-nographic -serial stdio \
\
-drive file=$DISK,if=none,id=drive0 \
-device virtio-blk,drive=drive0 \
\
-drive file=test-cidata.iso,media=cdrom \
\
-netdev user,hostfwd=::5-:22,id=net0 \
-device virtio-net,netdev=net0

$ ssh ubuntu@127.0.0.1 -p 5

$ lsb_release -cs
No LSB modules are available.
noble

$ uname -m
armv7l

$ uname -rv
6.5.0-9-generic #9-Ubuntu SMP Fri Oct  6 23:14:49 UTC 2023


kdump-tools

sudo apt update && sudo apt install -y linux-crashdump # No, Yes
# kernel cmdline parameter crashkernel=512M already in qemu cmdline
sudo reboot

$ sudo dmesg | grep 'crashkernel'
[0.00] crashkernel reservation failed - No suitable area found.

$ sudo cat /proc/iomem
...
4000-bfff : System RAM
  40308000-41df : Kernel code
  4200-4230ff8f : Kernel data

$ echo $(( 0x4000 / 1024**2))
1024

$ echo $(( (0xbfff + 1) / 1024 ** 2 ))
3072

Try at 2G address, i.e., crashkernel=512M@2G

$ sudo dmesg | grep crashkernel
[0.00] Reserving 512MB of memory at 2048MB for crashkernel 
(System RAM: 768MB)
[0.00] Kernel command line: root=LABEL=cloudimg-rootfs 
crashkernel=512M@2G

$ sudo kdump-config status
current state   : ready to kdump

crashdump

The VM never comes back from the kexec to the crashkernel;
apparently it fails/oops and the panic kernel/crashkernel hits a kernel 
panic too! :)

$ echo c | sudo tee /proc/sysrq-trigger

[  535.253829] sysrq: Trigger a crash
[  535.254672] Kernel panic - not syncing: sysrq triggered crash
[  535.255473] CPU: 0 PID: 1044 Comm: tee Kdump: loaded Not tainted 
6.5.0-9-generic #9-Ubuntu
[  535.255995] Hardware name: Generic DT based system
[  535.256568] Backtrace:
[  535.257928]  dump_backtrace from show_stack+0x20/0x38
[  535.259183]  r7: r6: r5:600d0093 r4:c1ab26a0
[  535.259711]  show_stack from dump_stack_lvl+0x48/0x68
[  535.260137]  dump_stack_lvl from dump_stack+0x18/0x28
[  535.260422]  r5:c2278a39 r4:c2278a24
[  535.260801]  dump_stack from panic+0x140/0x394
[  535.261081]  panic from sysrq_reset_seq_param_set+0x0/0xac
[  535.261374]  r3:c0df9ec4 r2: r1: r0:c1b774c8
[  535.261607]  r7:
[  535.261741]  sysrq_handle_crash from __handle_sysrq+0xc0/0x274
[  535.262006]  __handle_sysrq from write_sysrq_trigger+0x38/0x64
[  535.262311]  r10:f0c9df68 r9:0002 r8:bed97404 r7:c4b81cc0 
r6: r5:c0dfb488
[  535.262633]  r4:0002
[  535.262764]  write_sysrq_trigger from proc_reg_write+0xcc/0x104
[  535.263033]  r5:c0dfb488 r4:c2dcfb80
[  535.263192]  proc_reg_write from vfs_write+0xc4/0x3ec
[  535.263549]  r10:c428c800 r9:c0891b30 r8:c040031c r7:f0c9df68 
r6:c4d7d800 r5:c4b81cc0
[  535.264038]  r4:0002 r3:f0c9df68
[  535.264334]  vfs_write from ksys_write+0x80/0x114
[  535.264812]  r10:0004 r9:c4d7d800 r8:c040031c r7: 
r6: r5:c4b81cc0
[  535.265475]  r4:c4b81cc0
[  535.265847]  ksys_write from sys_write+0x18/0x2c
[  535.266474]  r7:0004 r6:01754a00 r5:bed97404 r4:0002
[  535.266740]  sys_write from ret_fast_syscall+0x0/0x4c
[  535.267185] Exception stack(0xf0c9dfa8 to 0xf0c9dff0)
[  535.267578] dfa0:   0002 bed97404 0003 
bed97404 0002 0001
[  535.267911] dfc0: 0002 bed97404 01754a00 0004 0002 
0002 bed97404 017554b0
[  535.268267] dfe0: 0004 bed97350 b6ef7ca3 b6e689c6
[  535.271397] CPU 1 will stop doing anything useful since another CPU 
has crashed
[  535.278326] Loading crashdump kernel...
[  535.283379] 8<--- cut here ---
[  535.285957] Unable to handle kernel NULL pointer dereference at 
virtual address  when write
[  

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

common for arm64, ppc64el, s390x, armhf:
---

cloud-init data iso:

echo 'local-hostname: test' >meta-data

PUBKEY=$(cat $HOME/.ssh/id_rsa.pub)

cat >/etc/ssh/sshd_config
   - restart ssh
EOF

genisoimage -output test-cidata.iso -volid cidata -joliet -rock
user-data meta-data

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  ...

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source

  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source

  ...

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

  ...

  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

ppc64el
---

vm

SERIES=noble
ARCH=ppc64el
DISK=${SERIES}_${ARCH}.qcow2

wget 
https://cloud-images.ubuntu.com/$SERIES/current/${SERIES}-server-cloudimg-${ARCH}.img
qemu-img create -F qcow2 -b ${SERIES}-server-cloudimg-${ARCH}.img -f 
qcow2 $DISK 8G

sudo apt install -y qemu-system-ppc

qemu-system-ppc64 \
  -machine pseries -cpu POWER9 \
\
-smp cpus=2 -m 2048 \
-nodefaults -no-user-config \
-nographic -serial stdio \
\
-drive file=$DISK,if=none,id=drive0 \
-device virtio-blk,drive=drive0 \
\
-drive file=test-cidata.iso,media=cdrom \
\
-netdev user,hostfwd=::3-:22,id=net0 \
-device virtio-net,netdev=net0

$ ssh ubuntu@127.0.0.1 -p 3

$ lsb_release -cs
No LSB modules are available.
noble

$ uname -m
ppc64le

$ uname -rv
6.5.0-9-generic #9-Ubuntu SMP Fri Oct  6 20:21:54 UTC 2023


kdump-tools

sudo apt update && sudo apt install -y linux-crashdump # No, Yes
sudo sed 's/crashkernel=[^" ]\+/crashkernel=512M/' -i 
/etc/default/grub.d/kdump-tools.cfg
sudo update-grub && sudo reboot

...

$ sudo dmesg | grep 'crashkernel.*RAM'
[0.00] Reserving 512MB of memory at 512MB for crashkernel 
(System RAM: 2048MB)


$ sudo kdump-config status
current state   : ready to kdump

crashdump

$ echo c | sudo tee /proc/sysrq-trigger

$ find /var/crash
/var/crash
/var/crash/kexec_cmd
/var/crash/linux-image-6.5.0-9-generic-202311081556.crash
/var/crash/_usr_bin_mandb.6.crash
/var/crash/202311081556
/var/crash/202311081556/dump.202311081556
/var/crash/202311081556/dmesg.202311081556
/var/crash/kdump_lock

debug symbols

dpkg -l | awk '$2 ~ /linux-image-[0-9.-]+-generic/ { print $2, $3}' \
  | while read pkg version; do \
  dbgpkg="${pkg}-dbgsym"; \
  arch=$(dpkg --print-architecture); \
  wget 
"https://launchpad.net/ubuntu/+archive/primary/+files/${dbgpkg}_${version}_${arch}.ddeb;;
 \
done

ar p linux-image-*-dbgsym_*.ddeb data.tar.xz | tar xJ
--wildcards './usr/lib/debug/boot/vmlinux-*-generic'

crash (old)

# dpkg -s crash | grep Version:
Version: 8.0.2-1ubuntu1

# crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
crash: invalid structure member offset: module_core_size
   FILE: kernel.c  LINE: 3781  FUNCTION: module_init()

[/usr/bin/crash] error trace: 122094283e0 => 12208f5f830 =>
12209018148 => 122090b1ce0

crash (new)

sudo add-apt-repository -y ppa:mfo/noble-crash-v2 && sudo apt
install -y crash

$ dpkg -s crash | grep Version:
Version: 8.0.3+ds1-3ubuntu1


# crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
WARNING: active task ca233200 on cpu 1 not found in PID hash

  KERNEL: ./usr/lib/debug/boot/vmlinux-6.5.0-9-generic
DUMPFILE: /var/crash/202311081556/dump.202311081556  [PARTIAL DUMP]
CPUS: 2
DATE: Wed Nov  8 15:50:40 UTC 2023
  UPTIME: 00:23:57
LOAD AVERAGE: 0.48, 1.10, 1.68
   TASKS: 3
NODENAME: test
 RELEASE: 6.5.0-9-generic
 VERSION: #9-Ubuntu SMP Fri Oct  6 20:21:54 UTC 2023
 MACHINE: ppc64le  (1000 Mhz)
  MEMORY: 2 GB
   PANIC: "Kernel panic - not syncing: sysrq triggered crash"
 PID: 4548
 COMMAND: "tee"
TASK: ca233200  [THREAD_INFO: ca233200]
 CPU: 1
   STATE: TASK_RUNNING (PANIC)

crash> bt
PID: 4548 TASK: ca233200  CPU: 1COMMAND: "tee"
 R0:  c02fce48R1:  c4dbb890R2:  c2102600
 R3:  c4dbb8a8R4:  R5:  
 R6:  c4dbba58R7:  R8:  0001
 R9:  cb81bc00R10: R11: 
 R12: R13: c0007fffee80R14: 
 R15: 0001R16: df8cR17: dfe4
 R18: 0003R19: R20: df98
 R21: dfa8R22: 7fffc3c27840R23: 7ef5bb071a60
 R24: c3a61960R25: R26: 0004
 R27: c3872f08R28: c3c7ace0R29: c3c7ad20
 R30: c3cd2600R31: 
 NIP: c02fbfe4MSR: 80009033OR3: 
 CTR: LR:  c02fce48XER: 

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

arm64
-

vm

SERIES=noble
ARCH=arm64
DISK=${SERIES}_${ARCH}.qcow2

wget 
https://cloud-images.ubuntu.com/$SERIES/current/${SERIES}-server-cloudimg-${ARCH}.img
qemu-img create -F qcow2 -b ${SERIES}-server-cloudimg-${ARCH}.img -f 
qcow2 $DISK 8G

sudo apt install -y qemu-system-arm qemu-efi

dd if=/dev/zero of=flash1.img bs=1M count=64
dd if=/dev/zero of=flash0.img bs=1M count=64
dd if=/usr/share/qemu-efi/QEMU_EFI.fd of=flash0.img conv=notrunc

qemu-system-aarch64 \
-machine virt -cpu cortex-a57 \
-pflash flash0.img -pflash flash1.img \
\
-smp cpus=2 -m 2048 \
-nodefaults -no-user-config \
-nographic -serial stdio \
\
-drive file=$DISK,if=none,id=drive0 \
-device virtio-blk-device,drive=drive0 \
\
-drive file=test-cidata.iso,media=cdrom \
\
-netdev user,hostfwd=::2-:22,id=net0 \
-device virtio-net-device,netdev=net0


$ ssh ubuntu@127.0.0.1 -p 2

$ lsb_release -cs
No LSB modules are available.
noble

$ uname -m
aarch64

$ uname -rv
6.5.0-9-generic #9-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct  6 20:34:49 UTC 
2023

kdump-tools

sudo apt update && sudo apt install -y linux-crashdump # No, Yes
sudo sed 's/crashkernel=[^" ]\+/crashkernel=512M/' -i 
/etc/default/grub.d/kdump-tools.cfg
sudo update-grub && sudo reboot

$ sudo dmesg | grep 'crashkernel reserved:'
[0.00] crashkernel reserved: 0x9160 - 
0xb160 (512 MB)

$ sudo kdump-config status
 * Invalid symlink : /var/lib/kdump/initrd.img
 * Invalid symlink : /var/lib/kdump/vmlinuz
current state   : Not ready to kdump

$ sudo kdump-config reload
 * unloaded kdump kernel
 * Creating symlink /var/lib/kdump/vmlinuz
kdump-tools: Generating /var/lib/kdump/initrd.img-6.5.0-9-generic
 * Creating symlink /var/lib/kdump/initrd.img
 * loaded kdump kernel

$ sudo kdump-config status
current state   : ready to kdump

crashdump

$ echo c | sudo tee /proc/sysrq-trigger

$ find /var/crash
/var/crash
/var/crash/202311081722
/var/crash/202311081722/dmesg.202311081722
/var/crash/202311081722/dump.202311081722
/var/crash/kexec_cmd
/var/crash/kdump_lock
/var/crash/linux-image-6.5.0-9-generic-202311081722.crash

debug symbols

dpkg -l | awk '$2 ~ /linux-image-[0-9.-]+-generic/ { print $2, $3}' \
  | while read pkg version; do \
  dbgpkg="linux-image-unsigned-${pkg#linux-image-}-dbgsym"; \
  arch=$(dpkg --print-architecture); \
  wget 
"https://launchpad.net/ubuntu/+archive/primary/+files/${dbgpkg}_${version}_${arch}.ddeb;;
 \
done

ar p linux-image-unsigned-*-dbgsym_*.ddeb data.tar.xz | tar xJ
--wildcards './usr/lib/debug/boot/vmlinux-*-generic'

crash (old)

$ dpkg -s crash | grep Version:
Version: 8.0.2-1ubuntu1

$ crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
crash: invalid structure member offset: module_core_size
   FILE: kernel.c  LINE: 3781  FUNCTION: module_init()

[/usr/bin/crash] error trace: c5c23f9c => c58f2f84 =>
c5974d3c => c59e7330

crash (new)

sudo add-apt-repository -y ppa:mfo/noble-crash-v2 && sudo apt
install -y crash

$ dpkg -s crash | grep Version:
Version: 8.0.3+ds1-3ubuntu1

$ crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
WARNING: active task 41b7e480 on cpu 0 not found in PID hash
WARNING: active task 40104300 on cpu 1 not found in PID hash

  KERNEL: ./usr/lib/debug/boot/vmlinux-6.5.0-9-generic
DUMPFILE: /var/crash/202311081722/dump.202311081722  [PARTIAL DUMP]
CPUS: 2
DATE: Wed Nov  8 17:17:27 UTC 2023
  UPTIME: 01:25:18
LOAD AVERAGE: 0.27, 0.11, 0.16
   TASKS: 4
NODENAME: test
 RELEASE: 6.5.0-9-generic
 VERSION: #9-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct  6 20:34:49 UTC 2023
 MACHINE: aarch64  (unknown Mhz)
  MEMORY: 2.1 GB
   PANIC: "Kernel panic - not syncing: sysrq triggered crash"
 PID: 5111
 COMMAND: "tee"
TASK: 41b7e480  [THREAD_INFO: 41b7e480]
 CPU: 0
   STATE: TASK_RUNNING (PANIC)

crash> bt
PID: 5111 TASK: 41b7e480  CPU: 0COMMAND: "tee"
 #0 [80008404b8d0] machine_kexec at 800080182cf0
 #1 [80008404ba60] __crash_kexec at 80008033b2d8
 #2 [80008404bae0] panic at 

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

s390x
-

vm

sudo apt install -y qemu-system-s390x

qemu-system-s390x \
  -machine s390-ccw-virtio -cpu qemu \
\
-smp cpus=2 -m 2048 \
-nodefaults -no-user-config \
-nographic -serial stdio \
\
-drive file=$DISK,if=none,id=drive0 \
-device virtio-blk,drive=drive0 \
\
-drive file=test-cidata.iso,media=cdrom \
\
-netdev user,hostfwd=::4-:22,id=net0 \
-device virtio-net,netdev=net0

$ ssh ubuntu@127.0.0.1 -p 4

$ lsb_release -cs
No LSB modules are available.
noble

$ uname -m
s390x

$ uname -rv
6.5.0-9-generic #9-Ubuntu SMP Fri Oct  6 19:43:35 UTC 2023

kdump-tools

sudo apt update && sudo apt install -y linux-crashdump # No, Yes
sudo sed '/^parameters =/ s/$/ crashkernel=512M/' -i /etc/zipl.conf
sudo zipl && sudo reboot

$ sudo dmesg | grep 'crashkernel.*RAM'
[   26.793337] setup: Reserving 512MB of memory at 1510MB for 
crashkernel (System RAM: 1536MB)

$ sudo kdump-config status
current state   : ready to kdump

crashdump

$ echo c | sudo tee /proc/sysrq-trigger

$ find /var/crash
/var/crash
/var/crash/linux-image-6.5.0-9-generic-202311081631.crash
/var/crash/202311081631
/var/crash/202311081631/dump.202311081631
/var/crash/202311081631/dmesg.202311081631
/var/crash/kexec_cmd
/var/crash/kdump_lock

debug symbols

dpkg -l | awk '$2 ~ /linux-image-[0-9.-]+-generic/ { print $2, $3}' \
  | while read pkg version; do \
  dbgpkg="linux-image-unsigned-${pkg#linux-image-}-dbgsym"; \
  arch=$(dpkg --print-architecture); \
  wget 
"https://launchpad.net/ubuntu/+archive/primary/+files/${dbgpkg}_${version}_${arch}.ddeb;;
 \
done

ar p linux-image-unsigned-*-dbgsym_*.ddeb data.tar.xz | tar xJ
--wildcards './usr/lib/debug/boot/vmlinux-*-generic'

crash (old)

# dpkg -s crash | grep Version:
Version: 8.0.2-1ubuntu1

# crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
crash: invalid structure member offset: module_core_size
   FILE: kernel.c  LINE: 3781  FUNCTION: module_init()

[/usr/bin/crash] error trace: 2aa1be60c84 => 2aa1bb029f2 =>
2aa1bb951b2 => 2aa1bc0d668

crash (new)

sudo add-apt-repository -y ppa:mfo/noble-crash-v2 && sudo apt
install -y crash

# dpkg -s crash | grep Version:
Version: 8.0.3+ds1-3ubuntu1

$ crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
WARNING: active task 3833600 on cpu 1 not found in PID hash

  KERNEL: ./usr/lib/debug/boot/vmlinux-6.5.0-9-generic
DUMPFILE: /var/crash/202311081631/dump.202311081631  [PARTIAL DUMP]
CPUS: 2
DATE: Wed Nov  8 16:22:13 UTC 2023
  UPTIME: 00:23:37
LOAD AVERAGE: 0.02, 0.57, 1.58
   TASKS: 3
NODENAME: test
 RELEASE: 6.5.0-9-generic
 VERSION: #9-Ubuntu SMP Fri Oct  6 19:43:35 UTC 2023
 MACHINE: s390x  (unknown Mhz)
  MEMORY: 2 GB
   PANIC: "Kernel panic - not syncing: sysrq triggered crash"
 PID: 4610
 COMMAND: "tee"
TASK: 3833600  [THREAD_INFO: 3833600]
 CPU: 1
   STATE: TASK_RUNNING (PANIC)

crash> bt
...
 #0 [380002179a8] smp_call_ipl_cpu at 11e2fe
 #1 [380002179c8] __crash_kexec at 2adfaa
 #2 [38000217ac0] panic at 1a8208
 #3 [38000217b68] sysrq_reset_seq_param_set at a3f860
 #4 [38000217b80] __handle_sysrq at a4055e
 #5 [38000217bf8] write_sysrq_trigger at a4100c
 #6 [38000217c30] proc_reg_write at 60dc9e
 #7 [38000217c80] vfs_write at 5470d4
 #8 [38000217d40] ksys_write at 547600
 #9 [38000217d90] __do_syscall at e77730
#10 [38000217e98] system_call at e89b58
...
crash> quit

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  ...

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source

  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source

  ...

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing 

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

The test packages in `ppa:mfo/noble-crash-v2` have worked well
(ie, crash can actually start, and is able to get a backtrace)
in amd64, arm64, ppc64el, and s390x (armhf couldn't even kexec).

This is a lot better than the current state (crash quits early)
in all these architectures, so I will move forward and propose
the merge request patchset.

Test logs/commands for each arch follow in the next comments.

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  ...

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source

  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source

  ...

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

  ...

  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

Upstream patch 'Support-module-memory-layout-change-on-Linux-6.4'
is required to crash to open a 6.5 kernel crashdump on Noble too.

# crash ./usr/lib/debug/boot/vmlinux-*-generic /var/crash/*/dump.*
...
crash: invalid structure member offset: module_core_size
   FILE: kernel.c  LINE: 3781  FUNCTION: module_init()

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  ...

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source

  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source

  ...

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

  ...

  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

Testing on amd64, arm64, armhf, ppc64el, and s390x with QEMU VMs.

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  ...

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source

  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source

  ...

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

  ...

  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

The package built successfully in all architectures (amd64, arm64,
armhf, ppc64el, s390x).

The PPA does not have riscv64 enabled, but it crash/riscv64 FTBFS in 
mantic-release,
which is in noble now, so even if it fails, it is not a regression from latest 
state.

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  ...

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source

  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source

  ...

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

  ...

  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3+ds1-3 into Noble

[Mauricio Faria de Oliveira]

Merged with Debian (8.0.3+ds1-3), now building (ppa:mfo/crash-noble).

** Summary changed:

- Merge crash 8.0.3 into Noble
+ Merge crash 8.0.3+ds1-3 into Noble

** Description changed:

- Work in progress; rebasing on 8.0.3+ds1-3, and testing.
+ Work in progress; rebased on 8.0.3+ds1-3, now building (ppa:mfo/crash-
+ noble), and testing.
  
  Debian bugs:
  
  https://bugs.debian.org/1054805
  Please update crash to 8.0.3
  
  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

** Description changed:

- Work in progress; rebased on 8.0.3+ds1-3, now building (ppa:mfo/crash-
- noble), and testing.
+ Work in progress; rebasing on 8.0.3+ds1-3, and testing.
+ 
+ ...
+ 
+ $ rmadison -a source crash | grep noble
+  crash | 8.0.2-1ubuntu1 | noble  | source
+ 
+ $ rmadison -a source crash -u debian | grep 'unstable '
+ crash  | 8.0.2-1   | unstable   | source
+ crash  | 8.0.3+ds1-3   | unstable   | source
+ 
+ ...
  
  Debian bugs:
  
  https://bugs.debian.org/1054805
  Please update crash to 8.0.3
  
  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

** Description changed:

  Work in progress; rebasing on 8.0.3+ds1-3, and testing.
  
  ...
  
  $ rmadison -a source crash | grep noble
-  crash | 8.0.2-1ubuntu1 | noble  | source
+  crash | 8.0.2-1ubuntu1 | noble  | source
  
  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source
  
  ...
  
  Debian bugs:
  
  https://bugs.debian.org/1054805
  Please update crash to 8.0.3
  
  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz
+ 
+ ...
+ 
+ Docs:
+ 
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

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

Title:
  Merge crash 8.0.3+ds1-3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  Fix Released

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  ...

  $ rmadison -a source crash | grep noble
   crash | 8.0.2-1ubuntu1 | noble  | source

  $ rmadison -a source crash -u debian | grep 'unstable '
  crash  | 8.0.2-1   | unstable   | source
  crash  | 8.0.3+ds1-3   | unstable   | source

  ...

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

  ...

  Docs:
  
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 1829563] Re: bcache: risk of data loss on I/O errors in backing or caching devices

[Mauricio Faria de Oliveira]

** Attachment added: "dm_fake_dev.sh"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829563/+attachment/5716855/+files/dm_fake_dev.sh

-- 
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/1829563

Title:
  bcache: risk of data loss on I/O errors in backing or caching devices

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Won't Fix
Status in linux source package in Disco:
  Fix Released
Status in linux source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * The bcache code in Bionic lacks several fixes to handle
     I/O errors in both backing devices and caching devices.

   * Partial or permanent errors in backing or caching devices,
     specially in writeback mode, can lead to data loss and/or
     the application is not notified about failed I/O requests.

   * The bcache device might remain available for I/O requests
     even if backing device is offline, so writes are undefined.

  [Test Case]

   * Detailed test cases/steps for the behavior of many patches
     with code logic changes are provided in bug comments.

   * The patchset has been tested for regressions on each cache
     mode (writethrough, writeback, writearound, none) with the
     xfstests test suite (on ext4) and fio (sequential + random
     read-write).

  [Regression Potential]

   * The patchset is relatively large and touches several areas
     in bcache code, however, synthetic testing of the patches
     has been performed, and extensive regression/stress tests
     were run (as mentioned in Test Case section).

   * Many patches in the patchset are 'Fixes' patches to other
     patches, and no further 'Fixes' currently exist upstream.

  [Other Info]

   * Canonical Field Eng. deploys bcache+writeback extensively
     (e.g., BootStack, UA cloud, except rare all-flash cases).

  [Original Bug Description]

  This is a request for a backport of the following upstream patch from
  4.18:

  "bcache: stop bcache device when backing device is offline"
  
https://github.com/torvalds/linux/commit/0f0709e6bfc3ce4e8e1c0e8573490c45f76cfeee

  Field engineering uses bcache quite extensively and it would be good
  to have this in the GA/bionic kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829563/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3 into Noble

[Mauricio Faria de Oliveira]

** Description changed:

- 2023/10/31: please do not merge 8.0.3-1 yet (issue with .orig tarball)
- 
- Work in progress; testing changes on PPA.
+ Work in progress; rebasing on 8.0.3+ds1-3, and testing.
  
  Debian bugs:
  
  https://bugs.debian.org/1054805
  Please update crash to 8.0.3
  
  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

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

Title:
  Merge crash 8.0.3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  New

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3 into Noble

[Mauricio Faria de Oliveira]

Debian crash 8.0.3+ds1-3 [1] addressed the gdb tarball issue.

I'll update the merge, and proceed with build and tests.

[1] https://tracker.debian.org/news/1475695/accepted-
crash-803ds1-3-source-into-unstable/

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

Title:
  Merge crash 8.0.3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  New

Bug description:
  Work in progress; rebasing on 8.0.3+ds1-3, and testing.

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3 into Noble

[Mauricio Faria de Oliveira]

** Description changed:

+ 2023/10/31: DO NOT MERGE 8.0.3-1 yet (issue with .orig tarball)
+ 
  Work in progress; testing changes on PPA.
  
  Debian bugs:
  
  https://bugs.debian.org/1054805
  Please update crash to 8.0.3
  
  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

** Description changed:

- 2023/10/31: DO NOT MERGE 8.0.3-1 yet (issue with .orig tarball)
+ 2023/10/31: please do not merge 8.0.3-1 yet (issue with .orig tarball)
  
  Work in progress; testing changes on PPA.
  
  Debian bugs:
  
  https://bugs.debian.org/1054805
  Please update crash to 8.0.3
  
  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

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

Title:
  Merge crash 8.0.3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  New

Bug description:
  2023/10/31: please do not merge 8.0.3-1 yet (issue with .orig tarball)

  Work in progress; testing changes on PPA.

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3 into Noble

[Mauricio Faria de Oliveira]

The package built successfully in a PPA with all supported architectures 
(!riscv64).
Now waiting on the Debian issue with the gdb-10.2.tar.gz tarball to be 
addressed.

Test build in ppa:mfo/noble-crash,

```
crash (8.0.3-1ubuntu1+gdb102targz.2) noble; urgency=medium

  * Merge with Debian unstable. Remaining changes: (LP: #2042357)
- d/t/live: If the "live" autopkgtest fails with a recommendation
  to try /proc/kcore instead of the default, attempt that before
  failing the test. [7.2.6-1ubuntu1]
- d/t/live: Fix logic issue in "live" autopkgtest introduced in
   the last upload. [7.2.6-1ubuntu2]
- d/t/live: Fix test, as if will return 0 when no cases were true.
  [7.2.8-1ubuntu1]
- d/t/control: Add linux-libc-dev dependency for the autopkg test.
  This package gets usually broken with kernel upgrades, so let it
  already show in the autopkg test. [7.2.9-2ubuntu3]
- d/t/control: Run autopkg test with allow-stderr. [8.0.0-1ubuntu1]
  * Dropped changes:
- Build without lto. Fails to build gdb on ppc64el. That should be
  fixed, once gdb is updated to a more recent version (e.g. 10.x).
  [7.2.9-2ubuntu2]
  * Added changes:
- d/p/0002-Fix-compilation-error-due-to-new-strlcpy-function.patch:
  Fix FTBFS due to strlcpy() introduced in glibc 2.38.

crash (8.0.3-1) unstable; urgency=medium

  * New upstream (Closes: #1054805)
  * https://github.com/crash-utility/crash/compare/8.0.2...8.0.3

 -- Mauricio Faria de Oliveira   Tue, 31 Oct 2023 14:09:03 
-0300
```

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

Title:
  Merge crash 8.0.3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  New

Bug description:
  Work in progress; testing changes on PPA.

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3 into Noble

[Mauricio Faria de Oliveira]

** Bug watch added: Debian Bug tracker #1054805
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054805

** Also affects: crash via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054805
   Importance: Unknown
   Status: Unknown

** Bug watch added: Debian Bug tracker #1055117
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055117

** Also affects: crash (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055117
   Importance: Unknown
   Status: Unknown

** No longer affects: crash

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

Title:
  Merge crash 8.0.3 into Noble

Status in crash package in Ubuntu:
  In Progress
Status in crash package in Debian:
  New

Bug description:
  Work in progress; testing changes on PPA.

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] Re: Merge crash 8.0.3 into Noble

[Mauricio Faria de Oliveira]

** Description changed:

- Work in progress
+ Work in progress; testing changes on PPA.
+ 
+ Debian bugs:
+ 
+ https://bugs.debian.org/1054805
+ Please update crash to 8.0.3
+ 
+ https://bugs.debian.org/1055117
+ FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

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

Title:
  Merge crash 8.0.3 into Noble

Status in crash package in Ubuntu:
  In Progress

Bug description:
  Work in progress; testing changes on PPA.

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2042357] [NEW] Merge crash 8.0.3 into Noble

[Mauricio Faria de Oliveira]

Public bug reported:

Work in progress; testing changes on PPA.

Debian bugs:

https://bugs.debian.org/1054805
Please update crash to 8.0.3

https://bugs.debian.org/1055117
FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

** Affects: crash (Ubuntu)
 Importance: Medium
 Assignee: Mauricio Faria de Oliveira (mfo)
 Status: In Progress

** Changed in: crash (Ubuntu)
   Status: New => Incomplete

** Changed in: crash (Ubuntu)
   Status: Incomplete => In Progress

** Changed in: crash (Ubuntu)
   Importance: Undecided => Medium

** Changed in: crash (Ubuntu)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

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

Title:
  Merge crash 8.0.3 into Noble

Status in crash package in Ubuntu:
  In Progress

Bug description:
  Work in progress; testing changes on PPA.

  Debian bugs:

  https://bugs.debian.org/1054805
  Please update crash to 8.0.3

  https://bugs.debian.org/1055117
  FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2042357/+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

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Debian's crash 8.0.3-1 FTBFS, waiting on 8.0.3-2 [1].

[1] https://bugs.debian.org/1055117

** Bug watch added: Debian Bug tracker #1055117
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055117

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Incomplete
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  In Progress
Status in crash source package in Mantic:
  In Progress

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as 

[Kernel-packages] [Bug 1931432] Re: crash FTBFS on riscv64

[Mauricio Faria de Oliveira]

** Changed in: crash (Ubuntu Groovy)
   Status: Confirmed => Won't Fix

** Changed in: crash (Ubuntu Groovy)
   Importance: Medium => Undecided

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

Title:
  crash FTBFS on riscv64

Status in crash package in Ubuntu:
  Confirmed
Status in crash source package in Focal:
  Confirmed
Status in crash source package in Groovy:
  Won't Fix

Bug description:
  Crash fails to build from source on riscv at least for Focal and
  Groovy, later releases may also be affected but I haven't confirm it.

  Examples of failed builds :

  Groovy : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630864
  Focal : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.04.1/+build/21630885

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931432/+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

[Kernel-packages] [Bug 2012060] Re: Crash doesn't open kdumps on Jammy with HWE kernel

[Mauricio Faria de Oliveira]

*** This bug is a duplicate of bug 2038249 ***
https://bugs.launchpad.net/bugs/2038249

** This bug has been marked a duplicate of bug 2038249
   The dump file parsing issue arises from structural changes in Linux kernel 
6.2

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

Title:
  Crash doesn't open kdumps on Jammy with HWE kernel

Status in crash package in Ubuntu:
  New

Bug description:
  Hi!

  I'm running Ubuntu with HWE kernel 5.19.0-35-generic. The kernel
  contains slab struct changes [1] that break crash 8.0.0. The issue has
  been fixed [3] in commit 14f8c460473c ("memory: Handle struct slab
  changes on Linux 5.17-rc1 and later"). The fix is available in crash
  8.0.1 and above.

  If you wish I can send a merge request to jammy-devel with this single
  patch but for now it seems that Ubuntu's process with regards to this
  package is just bump it to the newer version from debian.

  Please advice how to proceed. For now I just build the latest version
  of crash and I can open kdumps from Jammy with HWE using it.

  1. https://lwn.net/Articles/881039/
  2. https://bugzilla.redhat.com/show_bug.cgi?id=2041702
  3. 
https://github.com/crash-utility/crash/commit/14f8c460473c8613553b5defd174ca2af812ddcb

  $ lsb_release -rd
  Description:Ubuntu 22.04.2 LTS
  Release:22.04

  $ apt-cache policy crash
  crash:
Installed: 8.0.0-1ubuntu1
Candidate: 8.0.0-1ubuntu1
Version table:
   *** 8.0.0-1ubuntu1 500
  500 http://th.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2012060/+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

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

(Comment #8)

> Submitted bug [1] (wishlist) to Debian maintainer to update crash from 8.0.2 
> to 8.0.3 (released April/2023) in sid/unstable.
> With this we could merge a smaller set of changes later on.
> [1] https://bugs.debian.org/1054805

Crash 8.0.3 should soon be available in Debian, and we can merge it into Noble
with a few more recent fixes for the 6.x kernels (Noble is 6.5+), which we'll
need to SRU in older releases too (Mantic is 6.5, Lunar is 6.2, Jammy HWE is 
6.2 now, will be 6.5).

https://tracker.debian.org/news/1474801/accepted-crash-803-1-source-
into-unstable/

** Bug watch added: Debian Bug tracker #1054805
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054805

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Incomplete
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  In Progress
Status in crash source package in Mantic:
  In Progress

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Hi Chengen,

Thanks for the great work for these SRUs.

I'd like to suggest an update/improvement to the Test Plan section.
Even though crash is so broken that it can't even open a file,
once it starts working at all, it would be important to check
that it is working _correctly_.

So, please, could you add verifications for basic correctness
of the commands being addressed per patch (for GA and HWE)?
e.g., kmem -s|-S, module memory layout, etc.

And I had questions on 2 patches:

Patch 3:
---

 31 +* commit e36ce448a08d removed kmem_cache.freelist_cache in 6.1,
 32 +* so use freelist_size instead.
 33  */
 34 -   if (MEMBER_EXISTS("kmem_cache", "freelist_cache")) {
 35 +   if (MEMBER_EXISTS("kmem_cache", "freelist_size")) {

This is an inconditional change before/after 6.1, which thus could
impact Jammy, as it ships both 5.15 and 6.2 kernels.

However, it seems the (new value) attribute 'freelist_size' already
exists, so it should be fine in Jammy _if_ 5.15 has it too.

Could you please confirm?

Patch 5:
---

Some of this backport's context update is because this patch is not included,
and it would also fit the 6.2 criteria (changes in 6.1). It seems only code
adds though, not sure how it changes any behavior (or more patches needed).

Can you clarify if it's not really needed for 6.5? 
(I haven't followed the maple tree closely, but the commit message suggests 
it's important.)

If it's not needed _right_ now, i.e., if this SRU is priority, and crash
at least _works_ (which is a good improvement), I think it would be fine
to add it later.

commit 872cad2d63b3a07f65323fe80a7abb29ea276b44
Author: Tao Liu 
Date:   Tue Jan 10 14:56:27 2023 +0800

Port the maple tree data structures and functions

There have been two ways to iterate vm_area_struct until Linux 6.0:
 1) by rbtree, aka vma.vm_rb;
 2) by linked list, aka vma.vm_{next,prev}.
However with the maple tree patches[1][2] in Linux 6.1, vm_rb and
vm_{next,prev} are removed from vm_area_struct. The vm_area_dump()
in crash mainly uses the linked list for vma iteration, which will
not work for this case. So the maple tree iteration needs to be
ported to crash.

This patch 5 is also big, adding a lot, anyway, but it goes to gdb-10.2.patch,
which only changed context lines for the backport, indeed.

A pure-code review against upstream seems a big effort (~2000 lines, I managed
up to ~1000, and it seems to match upstream).

I guess this patch will be reasonably verified if the crash commands to show 
module memory layout on kernel 6.4+ (6.5 in our case) run correctly.


** Changed in: crash (Ubuntu)
   Status: In Progress => Incomplete

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Incomplete
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  In Progress
Status in crash source package in Mantic:
  In Progress

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

The version in Noble is still the same as in Mantic, and Debian does not
have a newer version either to sync/merge [1], so it apparently will not
change soon.

Let's proceed with the Mantic debdiff plus changes for Noble.

Changes:
- Modified d/changelog style to '* Description (LP: #)' entry with '- 
d/p/.patch' sub-entries (more common).
- Numbered the patches (1-7).

Great work on DEP-3 headers, thank you! (Bug-Ubuntu, Origin, and
backport notes; all matching.)

I checked there have been no changes from these patches upstream (i.e.,
fix-up commits to add; except for patch 5 mentioned later, with another
strategy).

I'll attach the updated debdiff for now (keeping your name in signature
line, if you don't mind, as I haven't done serious changes).

...

$ rmadison -a source crash
 crash | 7.0.3-3ubuntu2 | trusty | source
 crash | 7.0.3-3ubuntu4.5   | trusty-updates | source
 crash | 7.1.4-1ubuntu4 | xenial | source
 crash | 7.2.1-1| bionic | source
 crash | 7.2.3+real-1~16.04.1   | xenial-updates | source
 crash | 7.2.8-1ubuntu0.18.04.2 | bionic-updates | source
 crash | 7.2.8-1ubuntu1 | focal  | source
 crash | 7.2.8-1ubuntu1.20.04.1 | focal-updates  | source
 crash | 8.0.0-1ubuntu1 | jammy  | source
 crash | 8.0.0-1ubuntu1 | lunar  | source
 crash | 8.0.2-1ubuntu1 | mantic | source
 crash | 8.0.2-1ubuntu1 | noble  | source

$ date
Fri Oct 27 05:10:39 PM -03 2023

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Incomplete
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  In Progress
Status in crash source package in Mantic:
  In Progress

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

** Patch added: "lp2038249-crash-noble.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2038249/+attachment/5713875/+files/lp2038249-crash-noble.debdiff

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  Incomplete
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  In Progress
Status in crash source package in Mantic:
  In Progress

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "aarch64-unknown-linux-gnu".
  Type "show 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Updating the bug description with the crash versions/tags which
_contains_ the commit IDs.

Verified with the provided commit list:

$ cat 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Submitted bug [1] (wishlist) to Debian maintainer to update crash from
8.0.2 to 8.0.3 (released April/2023) in sid/unstable.

With this we could merge a smaller set of changes later on.

[1] https://bugs.debian.org/1054805

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  In Progress
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  In Progress
Status in crash source package in Mantic:
  In Progress

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==

  In 8.0.1:
  - 14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  - 5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  - b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB

  In 8.0.2:
  - f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if 
vabits_actual is missing

  In 8.0.3:
  - d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  - df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  - 120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  - ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later

  In 8.0.3++ (8.0.4 development)
  - 7750e61fdb2a Support module memory layout change on Linux 6.4
  - 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  - 4ee56105881d Fix compilation error due to new strlcpy function that glibc  
added

  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was 

[Kernel-packages] [Bug 2038249] Re: The dump file parsing issue arises from structural changes in Linux kernel 6.2

[Mauricio Faria de Oliveira]

Marking Jammy as affected due to the 6.2+ HWE kernel from Lunar (and
later).

** Also affects: crash (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: crash (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: crash (Ubuntu Jammy)
 Assignee: (unassigned) => Chengen Du (chengendu)

** Changed in: crash (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: crash (Ubuntu Lunar)
   Importance: Undecided => Medium

** Changed in: crash (Ubuntu Mantic)
   Importance: Undecided => Medium

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

Title:
  The dump file parsing issue arises from structural changes in Linux
  kernel 6.2

Status in crash package in Ubuntu:
  In Progress
Status in crash source package in Jammy:
  In Progress
Status in crash source package in Lunar:
  In Progress
Status in crash source package in Mantic:
  In Progress

Bug description:
  [Impact]
  Linux kernel 6.2 includes patches with structural changes that may render the 
crash utility unable to parse the dump file.
  ==
  d122019bf061 mm: Split slab into its own type
  401fb12c68c2 mm: Differentiate struct slab fields by sl*b implementations
  07f910f9b729 mm: Remove slab from struct page
  0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible
  e36ce448a08d mm/slab: use kmalloc_node() for off slab freelist_idx_t array 
allocation
  130d4df57390 mm/sl[au]b: rearrange struct slab fields to allow larger rcu_head
  ac3b43283923 module: replace module_layout with module_memory
  b69f0aeb0689 pid: Replace struct pid 1-element array with flex-array
  ==

  [Fix]
  It is advisable to adopt commits that address the structural changes issue.
  ==
  [v8.0.0]
  14f8c460473c memory: Handle struct slab changes on Linux 5.17-rc1 and later
  5f390ed811b0 Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  b89f9ccf511a Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB
  [v8.0.1]
  f02c8e87fccb arm64: use TCR_EL1_T1SZ to get the correct info if vabits_actual 
is missing
  [v8.0.2]
  d83df2fb66cd SLUB: Fix for offset change of struct slab members on Linux 
6.2-rc1
  df1f0cba729f x86_64: Fix for move of per-cpu variables into struct pcpu_hot
  120d6e89fc14 SLAB: Fix for "kmem -s|-S" options on Linux 6.1 and later
  ac96e17d1de5 SLAB: Fix for "kmem -s|-S" options on Linux 6.2-rc1 and later
  7750e61fdb2a Support module memory layout change on Linux 6.4
  88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and later
  4ee56105881d Fix compilation error due to new strlcpy function that glibc 
added
  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  crash 8.0.0
  Copyright (C) 2002-2021  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2021  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
   
  WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  GNU gdb (GDB) 10.2
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU 

[Kernel-packages] [Bug 2038248] Re: Slab page exclusion issue on Linux 6.2-rc1

[Mauricio Faria de Oliveira]

Uploaded to Jammy too.

The SRU template is now updated to reflect that.

Packages verified with LXD VM and upstream crash for the 6.2 kernel for now 
(before bug 2038248) and Ubuntu crash for the 5.15 GA kernel. All good!
(Details in comment #7.)

The package built correctly in a PPA on all architectures.


** Changed in: makedumpfile (Ubuntu Jammy)
   Status: Confirmed => In Progress

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

Title:
  Slab page exclusion issue on Linux 6.2-rc1

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Jammy:
  In Progress
Status in makedumpfile source package in Lunar:
  In Progress

Bug description:
  [Impact]

  The kernel crashdumps generated by makedumpfile on kernel 6.2
  (affects Lunar, and Jammy with the HWE kernel) might not open
  on crash, due to kernel changes not reflected in makedumpfile.

  The Kernel commit 130d4df57390 ("mm/sl[au]b: rearrange struct slab fields to 
allow larger rcu_head"), included in Linux 6.2-rc1 and later versions, 
introduced a change that aligns the offset of slab.slabs with that of 
page.mapping.
  However, this modification unintentionally causes the makedumpfile command 
with the -d 8 option, meant to exclude user data, to incorrectly exclude 
certain slab pages.
  Consequently, when utilizing dumpfiles generated in this manner, the "crash" 
utility may encounter an error when attempting to initiate a session:

  crash: page excluded: kernel virtual address: e269d428  type:
  "xa_node shift"

  [Fix]

  An upstream fix is available.
  ==
  commit 5f17bdd2128998a3eeeb4521d136a19fadb6
  Author: Kazuhito Hagio 
  Date:   Wed Dec 21 11:06:39 2022 +0900

  [PATCH] Fix wrong exclusion of slab pages on Linux 6.2-rc1
  ==

  [Test Plan]

  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot

  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  # crash dbgsym-$(uname -r)/usr/lib/debug/boot/vmlinux-$(uname -r) 
/dump.
  ...
  please wait... (gathering task table data)
  crash: page excluded: kernel virtual address: e269d428  type: 
"xa_node shift"

  [Where problems could occur]

  The patch has altered the method for excluding slab pages, aligning with the 
structural changes introduced in Linux 6.2-rc1.
  This modification is essential for Linux kernel 6.2.
  However, it's crucial to note that this change may impact the content of the 
dump file, potentially leading to a situation where the "crash" utility is 
unable to parse it in the worst-case scenario.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/2038248/+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

[Kernel-packages] [Bug 2038248] Re: Slab page exclusion issue on Linux 6.2-rc1

[Mauricio Faria de Oliveira]

** Description changed:

  [Impact]
+ 
+ The kernel crashdumps generated by makedumpfile on kernel 6.2
+ (affects Lunar, and Jammy with the HWE kernel) might not open
+ on crash, due to kernel changes not reflected in makedumpfile.
+ 
  The Kernel commit 130d4df57390 ("mm/sl[au]b: rearrange struct slab fields to 
allow larger rcu_head"), included in Linux 6.2-rc1 and later versions, 
introduced a change that aligns the offset of slab.slabs with that of 
page.mapping.
  However, this modification unintentionally causes the makedumpfile command 
with the -d 8 option, meant to exclude user data, to incorrectly exclude 
certain slab pages.
  Consequently, when utilizing dumpfiles generated in this manner, the "crash" 
utility may encounter an error when attempting to initiate a session:
  
  crash: page excluded: kernel virtual address: e269d428  type:
  "xa_node shift"
  
  [Fix]
+ 
  An upstream fix is available.
  ==
  commit 5f17bdd2128998a3eeeb4521d136a19fadb6
  Author: Kazuhito Hagio 
  Date:   Wed Dec 21 11:06:39 2022 +0900
  
- [PATCH] Fix wrong exclusion of slab pages on Linux 6.2-rc1
+ [PATCH] Fix wrong exclusion of slab pages on Linux 6.2-rc1
  ==
  
  [Test Plan]
+ 
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
+ 
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
-/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
- kdump initrd: 
-/var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
+    /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
+ kdump initrd:
+    /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump
  
  kexec command:
-   /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
+   /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
+ 
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  # crash dbgsym-$(uname -r)/usr/lib/debug/boot/vmlinux-$(uname -r) 
/dump.
- crash 8.0.3++
- Copyright (C) 2002-2022  Red Hat, Inc.
- Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
- Copyright (C) 1999-2006  Hewlett-Packard Co
- Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
- Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
- Copyright (C) 2005, 2011, 2020-2022  NEC Corporation
- Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
- Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
- Copyright (C) 2015, 2021  VMware, Inc.
- This program is free software, covered by the GNU General Public License,
- and you are welcome to change it and/or distribute copies of it under
- certain conditions.  Enter "help copying" to see the conditions.
- This program has absolutely no warranty.  Enter "help warranty" for details.
-  
- GNU gdb (GDB) 10.2 
- Copyright (C) 2021 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 or later 
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law.
- Type "show copying" and "show warranty" for details.
- This GDB was configured as "aarch64-unknown-linux-gnu".
- Type "show configuration" for configuration details.
- Find the GDB manual and other documentation resources online at:
- .
- 
- For help, type "help".
- Type "apropos word" to search for commands related to "word"...
- 
- please wait... (gathering task table data)  
+ ...
+ please wait... (gathering task table data)
  crash: page excluded: kernel virtual address: e269d428  type: 
"xa_node shift"
  
  [Where problems could occur]
+ 
  The patch has altered the method for excluding slab pages, aligning with the 
structural changes introduced in Linux 6.2-rc1.
  This modification is essential for 

[Kernel-packages] [Bug 2038248] Re: Slab page exclusion issue on Linux 6.2-rc1

[Mauricio Faria de Oliveira]

Jammy is also affected for the 6.2 HWE kernel.

The patch for makedumpfile is the same, and applies cleanly.
It fixes the issue with the 6.2 HWE kernel, and causes no regression with the 
5.15 GA kernel (ie, the dump file can still be opened in crash).


Details:
---

Setup:

$ lxc launch --vm --config limits.memory=2GiB ubuntu:jammy mdf-j
$ lxc shell mdf-j

# apt update && apt install -y linux-image-generic-hwe-22.04 
linux-crashdump crash
# apt remove -y $(dpkg -l | awk '$2 ~ /linux-.*kvm/ { print $2 }')

# sed 's/crashkernel=[^ "]\+/crashkernel=512M/' -i 
/etc/default/grub.d/kdump-tools.cfg
# update-grub
# reboot
# kdump-config show | grep state:
current state:ready to kdump
# echo c >/proc/sysrq-trigger

Debug symbols:

# wget 
https://launchpad.net/ubuntu/+archive/primary/+files/linux-image-unsigned-6.2.0-34-generic-dbgsym_6.2.0-34.34~22.04.1_amd64.ddeb
# ar x 
linux-image-unsigned-6.2.0-34-generic-dbgsym_6.2.0-34.34~22.04.1_amd64.ddeb 
data.tar.xz
# tar xvf data.tar.xz ./usr/lib/debug/boot/vmlinux-6.2.0-34-generic
./usr/lib/debug/boot/vmlinux-6.2.0-34-generic

Upstream crash (for now):

# apt build-dep -y crash
# git clone https://github.com/crash-utility/crash.git
# cd crash
# make

Original package:
---

# ./crash ./usr/lib/debug/boot/vmlinux-6.2.0-34-generic 
/var/crash/202310101134/dump.202310101134
...
please wait... (gathering task table data)
crash: page excluded: kernel virtual address: 9b13c2b826c8  type: 
"xa_node shift"

Patched package:
---

$ ./crash ./usr/lib/debug/boot/vmlinux-6.2.0-34-generic 
/var/crash/202310101206/dump.202310101206
...
 RELEASE: 6.2.0-34-generic
 VERSION: #34~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep  7 
13:12:03 UTC 2
...
crash>

Patched package & GA kernel:
---

(upstream crash and Ubuntu crash, both work)

$ ./crash ./usr/lib/debug/boot/vmlinux-5.15.0-86-generic 
/var/crash/202310101225/dump.202310101225
...
 RELEASE: 5.15.0-86-generic
 VERSION: #96-Ubuntu SMP Wed Sep 20 08:23:49 UTC 2023
...
crash>

$ crash ./usr/lib/debug/boot/vmlinux-5.15.0-86-generic 
/var/crash/202310101225/dump.202310101225
...
 RELEASE: 5.15.0-86-generic
 VERSION: #96-Ubuntu SMP Wed Sep 20 08:23:49 UTC 2023
...
crash>


** Changed in: makedumpfile (Ubuntu Jammy)
   Status: Incomplete => Confirmed

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

Title:
  Slab page exclusion issue on Linux 6.2-rc1

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Jammy:
  Confirmed
Status in makedumpfile source package in Lunar:
  In Progress

Bug description:
  [Impact]
  The Kernel commit 130d4df57390 ("mm/sl[au]b: rearrange struct slab fields to 
allow larger rcu_head"), included in Linux 6.2-rc1 and later versions, 
introduced a change that aligns the offset of slab.slabs with that of 
page.mapping.
  However, this modification unintentionally causes the makedumpfile command 
with the -d 8 option, meant to exclude user data, to incorrectly exclude 
certain slab pages.
  Consequently, when utilizing dumpfiles generated in this manner, the "crash" 
utility may encounter an error when attempting to initiate a session:

  crash: page excluded: kernel virtual address: e269d428  type:
  "xa_node shift"

  [Fix]
  An upstream fix is available.
  ==
  commit 5f17bdd2128998a3eeeb4521d136a19fadb6
  Author: Kazuhito Hagio 
  Date:   Wed Dec 21 11:06:39 2022 +0900

  [PATCH] Fix wrong exclusion of slab pages on Linux 6.2-rc1
  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the 

[Kernel-packages] [Bug 2038248] Re: Slab page exclusion issue on Linux 6.2-rc1

[Mauricio Faria de Oliveira]

(The package built correctly in a PPA on all architectures.)

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

Title:
  Slab page exclusion issue on Linux 6.2-rc1

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Jammy:
  Incomplete
Status in makedumpfile source package in Lunar:
  In Progress

Bug description:
  [Impact]
  The Kernel commit 130d4df57390 ("mm/sl[au]b: rearrange struct slab fields to 
allow larger rcu_head"), included in Linux 6.2-rc1 and later versions, 
introduced a change that aligns the offset of slab.slabs with that of 
page.mapping.
  However, this modification unintentionally causes the makedumpfile command 
with the -d 8 option, meant to exclude user data, to incorrectly exclude 
certain slab pages.
  Consequently, when utilizing dumpfiles generated in this manner, the "crash" 
utility may encounter an error when attempting to initiate a session:

  crash: page excluded: kernel virtual address: e269d428  type:
  "xa_node shift"

  [Fix]
  An upstream fix is available.
  ==
  commit 5f17bdd2128998a3eeeb4521d136a19fadb6
  Author: Kazuhito Hagio 
  Date:   Wed Dec 21 11:06:39 2022 +0900

  [PATCH] Fix wrong exclusion of slab pages on Linux 6.2-rc1
  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  # crash dbgsym-$(uname -r)/usr/lib/debug/boot/vmlinux-$(uname -r) 
/dump.
  crash 8.0.3++
  Copyright (C) 2002-2022  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2022  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
   
  GNU gdb (GDB) 10.2 
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "aarch64-unknown-linux-gnu".
  Type "show configuration" for configuration details.
  Find the GDB manual and other documentation resources online at:
  .

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...

  please wait... (gathering task table data)  
  crash: page excluded: kernel virtual address: e269d428  type: 
"xa_node shift"

  [Where problems could occur]
  The patch has altered the method for excluding slab pages, aligning with the 
structural changes introduced in Linux 6.2-rc1.
  This modification is essential for Linux kernel 6.2.
  However, it's crucial to note that this change may impact the content of the 
dump file, potentially leading to a situation where the "crash" utility is 
unable to parse it in the worst-case scenario.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/2038248/+subscriptions


-- 
Mailing list: 

[Kernel-packages] [Bug 2038248] Re: Slab page exclusion issue on Linux 6.2-rc1

[Mauricio Faria de Oliveira]

Hi Chengen,

The fix is included in 1.7.3 in mantic, so only lunar needs the fix.

We probably would like jammy as well, for compatibility with the 6.2+
HWE kernel (without regression to the 5.15 GA kernel).

Could you please check jammy for that too? (I'll add a task as
Incomplete.)

$ git describe --contains 5f17bdd2128998a3eeeb4521d136a19fadb6
1.7.3~6

$ rmadison -a source makedumpfile
 makedumpfile | 1.5.5-2ubuntu1   | trusty   | source
 makedumpfile | 1.5.5-2ubuntu1.6 | trusty-updates   | source
 makedumpfile | 1:1.5.9-5~ubuntu14.04.1  | trusty-backports | source
 makedumpfile | 1:1.5.9-5| xenial   | source
 makedumpfile | 1:1.6.3-2~16.04.3| xenial-updates   | source
 makedumpfile | 1:1.6.3-2| bionic   | source
 makedumpfile | 1:1.6.5-1ubuntu1~18.04.7 | bionic-updates   | source
 makedumpfile | 1:1.6.7-1ubuntu2 | focal| source
 makedumpfile | 1:1.6.7-1ubuntu2.4   | focal-updates| source
 makedumpfile | 1:1.7.0-1build1  | jammy| source
 makedumpfile | 1:1.7.2-1| lunar| source
 makedumpfile | 1:1.7.3-1| mantic   | source

Packages verified with LXD VM and upstream crash for now (before bug
2038248). All good!

Uploaded to Lunar.

Thanks!

Details:
---

Setup:

$ lxc launch --vm --config limits.memory=2GiB ubuntu:lunar mdf-l
$ lxc shell mdf-l

# apt update && apt install -y linux-image-generic linux-crashdump crash
# apt remove -y $(dpkg -l | awk '$2 ~ /linux-.*kvm/ { print $2 }')

# sed 's/crashkernel=[^ "]\+/crashkernel=512M/' -i 
/etc/default/grub.d/kdump-tools.cfg
# update-grub
# reboot
# kdump-config show | grep state:
current state:ready to kdump
# echo c >/proc/sysrq-trigger

Debug symbols:

# wget 
https://launchpad.net/ubuntu/+archive/primary/+files/linux-image-unsigned-6.2.0-34-generic-dbgsym_6.2.0-34.34_amd64.ddeb
# ar x 
linux-image-unsigned-6.2.0-34-generic-dbgsym_6.2.0-34.34_amd64.ddeb data.tar.xz
# tar xvf data.tar.xz ./usr/lib/debug/boot/vmlinux-6.2.0-34-generic
./usr/lib/debug/boot/vmlinux-6.2.0-34-generic

Upstream crash (for now):

# apt build-dep -y crash
# git clone https://github.com/crash-utility/crash.git
# cd crash
# make

Original package:
---

# ./crash /var/crash/202310072357/dump.202310072357 
./usr/lib/debug/boot/vmlinux-6.2.0-34-generic
...
please wait... (gathering task table data)
crash: page excluded: kernel virtual address: 9b13c2b826c8  type: 
"xa_node shift"

Patched package:
---

# wget 
https://launchpad.net/~mfo/+archive/ubuntu/test/+build/26759821/+files/makedumpfile_1.7.2-1ubuntu0.1_amd64.deb
# apt install ./makedumpfile_1.7.2-1ubuntu0.1_amd64.deb

# kdump-config reload
# kdump-config show | grep state:
current state:ready to kdump
# echo c >/proc/sysrq-trigger

# ./crash /var/crash/202310080054/dump.202310080054 
./usr/lib/debug/boot/vmlinux-6.2.0-34-generic
...
  KERNEL: ./usr/lib/debug/boot/vmlinux-6.2.0-34-generic
DUMPFILE: /var/crash/202310080054/dump.202310080054  [PARTIAL DUMP]
...
crash>


** Also affects: makedumpfile (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: makedumpfile (Ubuntu Jammy)
   Status: New => Incomplete

** Changed in: makedumpfile (Ubuntu Jammy)
 Assignee: (unassigned) => Chengen Du (chengendu)

** Changed in: makedumpfile (Ubuntu Lunar)
   Importance: Undecided => Medium

** Changed in: makedumpfile (Ubuntu Jammy)
   Importance: Undecided => Medium

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

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

Title:
  Slab page exclusion issue on Linux 6.2-rc1

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Jammy:
  Incomplete
Status in makedumpfile source package in Lunar:
  In Progress

Bug description:
  [Impact]
  The Kernel commit 130d4df57390 ("mm/sl[au]b: rearrange struct slab fields to 
allow larger rcu_head"), included in Linux 6.2-rc1 and later versions, 
introduced a change that aligns the offset of slab.slabs with that of 
page.mapping.
  However, this modification unintentionally causes the makedumpfile command 
with the -d 8 option, meant to exclude user data, to incorrectly exclude 
certain slab pages.
  Consequently, when utilizing dumpfiles generated in this manner, the "crash" 
utility may encounter an error when attempting to initiate a session:

  

[Kernel-packages] [Bug 2038248] Re: Slab page exclusion issue on Linux 6.2-rc1

[Mauricio Faria de Oliveira]

** Patch added: "lp2038248-makedumpfile-lunar-v2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/2038248/+attachment/5707762/+files/lp2038248-makedumpfile-lunar-v2.debdiff

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

Title:
  Slab page exclusion issue on Linux 6.2-rc1

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Lunar:
  In Progress

Bug description:
  [Impact]
  The Kernel commit 130d4df57390 ("mm/sl[au]b: rearrange struct slab fields to 
allow larger rcu_head"), included in Linux 6.2-rc1 and later versions, 
introduced a change that aligns the offset of slab.slabs with that of 
page.mapping.
  However, this modification unintentionally causes the makedumpfile command 
with the -d 8 option, meant to exclude user data, to incorrectly exclude 
certain slab pages.
  Consequently, when utilizing dumpfiles generated in this manner, the "crash" 
utility may encounter an error when attempting to initiate a session:

  crash: page excluded: kernel virtual address: e269d428  type:
  "xa_node shift"

  [Fix]
  An upstream fix is available.
  ==
  commit 5f17bdd2128998a3eeeb4521d136a19fadb6
  Author: Kazuhito Hagio 
  Date:   Wed Dec 21 11:06:39 2022 +0900

  [PATCH] Fix wrong exclusion of slab pages on Linux 6.2-rc1
  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  # crash dbgsym-$(uname -r)/usr/lib/debug/boot/vmlinux-$(uname -r) 
/dump.
  crash 8.0.3++
  Copyright (C) 2002-2022  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2022  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
   
  GNU gdb (GDB) 10.2 
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "aarch64-unknown-linux-gnu".
  Type "show configuration" for configuration details.
  Find the GDB manual and other documentation resources online at:
  .

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...

  please wait... (gathering task table data)  
  crash: page excluded: kernel virtual address: e269d428  type: 
"xa_node shift"

  [Where problems could occur]
  The patch has altered the method for excluding slab pages, aligning with the 
structural changes introduced in Linux 6.2-rc1.
  This modification is essential for Linux kernel 6.2.
  However, it's crucial to note that this change may impact the content of the 
dump file, potentially leading to a situation where the "crash" utility is 
unable to parse it in the worst-case scenario.

To manage notifications about this bug go to:

[Kernel-packages] [Bug 2038248] Re: Slab page exclusion issue on Linux 6.2-rc1

[Mauricio Faria de Oliveira]

Hi Chengen,

Thanks for the detailed SRU template and debdiff!

I have only 2 minor fixes, which I already performed:
- Version: s/ubuntu1/ubuntu0.1/ (see doc [1])
- Maintainer: this is the first 'ubuntu' version, so run `update-maintainer` 
(see `debian/control` hunk).

The updated debdiff is attached for reference,
and I'll continue the work on sponsoring this.

cheers

[1]
https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging

** Tags added: se-sponsor-mfo

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

Title:
  Slab page exclusion issue on Linux 6.2-rc1

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Lunar:
  In Progress

Bug description:
  [Impact]
  The Kernel commit 130d4df57390 ("mm/sl[au]b: rearrange struct slab fields to 
allow larger rcu_head"), included in Linux 6.2-rc1 and later versions, 
introduced a change that aligns the offset of slab.slabs with that of 
page.mapping.
  However, this modification unintentionally causes the makedumpfile command 
with the -d 8 option, meant to exclude user data, to incorrectly exclude 
certain slab pages.
  Consequently, when utilizing dumpfiles generated in this manner, the "crash" 
utility may encounter an error when attempting to initiate a session:

  crash: page excluded: kernel virtual address: e269d428  type:
  "xa_node shift"

  [Fix]
  An upstream fix is available.
  ==
  commit 5f17bdd2128998a3eeeb4521d136a19fadb6
  Author: Kazuhito Hagio 
  Date:   Wed Dec 21 11:06:39 2022 +0900

  [PATCH] Fix wrong exclusion of slab pages on Linux 6.2-rc1
  ==

  [Test Plan]
  1. Install the required packages and then proceed to reboot the machine.
  # sudo apt install crash linux-crashdump -y
  # reboot
  2. To check the status of kdump, use the `kdump-config show` command.
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 0x6400
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.2.0-33-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-6.2.0-33-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.2.0-33-generic 
root=UUID=3e72f5d5-870b-4b8e-9a0d-8ba920391379 ro console=tty1 console=ttyS0 
reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll 
usbcore.nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  3. To trigger a crash dump forcefully, execute the `echo c | sudo tee 
/proc/sysrq-trigger` command.
  4. Download the kernel .ddeb file, which will be used for analyzing the dump 
file.
  # sudo -i
  # cd /var/crash
  # pull-lp-ddebs linux-image-unsigned-$(uname -r)
  # dpkg-deb -x linux-image-unsigned-$(uname -r)-*.ddeb dbgsym-$(uname -r)
  5. Utilize the "crash" utility to parse and analyze the dump file.
  # crash dbgsym-$(uname -r)/usr/lib/debug/boot/vmlinux-$(uname -r) 
/dump.
  crash 8.0.3++
  Copyright (C) 2002-2022  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011, 2020-2022  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  Copyright (C) 2015, 2021  VMware, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
   
  GNU gdb (GDB) 10.2 
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "aarch64-unknown-linux-gnu".
  Type "show configuration" for configuration details.
  Find the GDB manual and other documentation resources online at:
  .

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...

  please wait... (gathering task table data)  
  crash: page excluded: kernel virtual address: e269d428  type: 
"xa_node shift"

  [Where problems could occur]
  The patch has altered the method for excluding slab pages, aligning with the 
structural changes introduced in Linux 6.2-rc1.
  This modification is essential for Linux kernel 6.2.
  

[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified

[Mauricio Faria de Oliveira]

** Changed in: linux (Ubuntu Jammy)
   Status: Fix Committed => Fix Released

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

Title:
  kdump fails on big arm64 systems when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in kexec-tools source package in Focal:
  Fix Released
Status in linux source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  Fix Released
Status in kexec-tools source package in Jammy:
  Fix Released
Status in linux source package in Jammy:
  Fix Released
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
  Invalid
Status in kexec-tools source package in Lunar:
  Fix Released
Status in kexec-tools source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.

  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel region.

  [Fix]

  To address this issue the following upstream commits are needed:

  - From the kernel side:

  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800

  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones

  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800

  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified

  - From kexec-tools:

  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800

  arm64: support more than one crash kernel regions

  Affected releases:
  Jammy, Focal, Bionic

  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.

  [Test Plan]

  You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump, configure the crash kernel size, and trigger a crash.

  1) Failing scenario (crashkernel >= 4G, without offset "@"):

  It won't work unless the offset is specified because the memory
  crashkernel cannot be allocated.

  With the patches applied it works as expected without having to
  specify the offset.

  2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G')

  This must continue to work with the new patches (ie, no regressions),
  including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
  Focal).

  [Regression Potential]

  KERNEL 5.15 - Jammy (and Focal via the HWE kernel):

  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.

  kexec-tools - FOCAL:

  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code without altering current functionality.
  Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive 
it moves the code from vmcore-dmesg.c  to elf_info.c so it can be used by other 
features.

  kexec-tools - JAMMY, LUNAR, MANTIC:

  Commit b5a34a20984c is pulled in, it cherry-picks. It changes only
  arm64 code. It enables kexec to recognise that the reserved kernel may
  use more than one kernel region. Things could go worng when gatherinng
  a crashdump.

  [Other]

  Commits to backport

  - MANTIC:

  kernel 6.3: not affected

  kexec-tools:
  b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one 
crash kernel regions

  - LUNAR:

  

[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified

[Mauricio Faria de Oliveira]

This bug has been fixed in Jammy, but not yet marked Fix Released
apparently due to an issue with the Launchpad bot (reported to the
Launchpad team); leaving as Fix Committed so to trigger when the bot
runs again for it.

linux (5.15.0-83.92) jammy; urgency=medium

  * kdump fails on big arm64 systems when offset is not specified (LP: #2024479)
- arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
- arm64: kdump: Reimplement crashkernel=X
- docs: kdump: Update the crashkernel description for arm64
- arm64: kdump: Do not allocate crash low memory if not needed
- arm64/mm: Define defer_reserve_crashkernel()
- arm64: kdump: Provide default size when crashkernel=Y, low is not 
specified
- arm64: kdump: Support crashkernel=X fall back to reserve region above DMA
  zones
  
That is also reflected in linux-hwe, see comment #37:
> This bug was fixed in the package linux-hwe-5.15 - 5.15.0-83.92~20.04.1

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

Title:
  kdump fails on big arm64 systems when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in kexec-tools source package in Focal:
  Fix Released
Status in linux source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  Fix Released
Status in kexec-tools source package in Jammy:
  Fix Released
Status in linux source package in Jammy:
  Fix Committed
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
  Invalid
Status in kexec-tools source package in Lunar:
  Fix Released
Status in kexec-tools source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.

  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel region.

  [Fix]

  To address this issue the following upstream commits are needed:

  - From the kernel side:

  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800

  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones

  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800

  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified

  - From kexec-tools:

  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800

  arm64: support more than one crash kernel regions

  Affected releases:
  Jammy, Focal, Bionic

  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.

  [Test Plan]

  You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump, configure the crash kernel size, and trigger a crash.

  1) Failing scenario (crashkernel >= 4G, without offset "@"):

  It won't work unless the offset is specified because the memory
  crashkernel cannot be allocated.

  With the patches applied it works as expected without having to
  specify the offset.

  2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G')

  This must continue to work with the new patches (ie, no regressions),
  including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
  Focal).

  [Regression Potential]

  KERNEL 5.15 - Jammy (and Focal via the HWE kernel):

  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.

  kexec-tools - FOCAL:

  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of 

[Kernel-packages] [Bug 2015400] Re: losetup with mknod fails on jammy with kernel 5.15.0-69-generic

[Mauricio Faria de Oliveira]

This bug has been fixed in Lunar and Jammy, but not yet marked Fix
Released apparently due to an issue with the Launchpad bot (reported to
the Launchpad team); leaving as Fix Committed so to trigger when the bot
runs again for it.

linux (6.2.0-32.32) lunar; urgency=medium
...
  * losetup with mknod fails on jammy with kernel 5.15.0-69-generic
(LP: #2015400)
- loop: deprecate autoloading callback loop_probe()
- loop: do not enforce max_loop hard limit by (new) default

@ https://launchpad.net/ubuntu/+source/linux/6.2.0-32.32

linux (5.15.0-83.92) jammy; urgency=medium
...
  * losetup with mknod fails on jammy with kernel 5.15.0-69-generic
(LP: #2015400)
- loop: do not enforce max_loop hard limit by (new) default

@ https://launchpad.net/ubuntu/+source/linux/5.15.0-83.92

-- 
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/2015400

Title:
  losetup with mknod fails on jammy with kernel 5.15.0-69-generic

Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  Invalid
Status in linux source package in Jammy:
  Fix Committed
Status in linux source package in Lunar:
  Fix Committed
Status in linux source package in Mantic:
  Invalid

Bug description:
  [ Impact ]

   * Regression in the loop block driver in Jammy kernel
     between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
     due to a change in the default behavior (value) of
     kernel parameter `max_loop` (from 0 to 8) in commit:
     `loop: Fix the max_loop commandline argument treatment
     when it is set to 0` (comment #6).

   * Users of loop devices (major 7) with minor >= 8 now
     fail to `open()` a loop device created with `mknod()`.

   * This is a corner case, as most people use `losetup`
     with usual /dev/loopNUMBER (or `--find`) which are
     not affected as it uses a different code path.
     (`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)

   * Workaround: kernel parameter `max_loop=0`.

  [ Test Steps ]

   * Run the test cases (losetup and test-loop.c in comment #6):
     - max_loop not set (default)
     - max_loop=0
     - max_loop=8

   * Verify the default behavior (max_loop not set) is restored.

   * Verify the modified behavior (max_loop is set) is unchanged.

  [ Regression Potential ]

   * Regressions would be limited to the loop block driver,
     more specifically its default behavior (but it's that now)
     or specific usage of max_loop parameter (tested; looks OK).

  [ Other Info ]

   * Patch 1 [1] is not quite a fix, but adds CONFIG guards that
 Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
 with that could be done, but Patch 1 seems trivial enough.)

   * The fix on Jammy is only Patch 2, with a trivial backport
 (that CONFIG option is not in Jammy/v5.15, only in v5.18).

   * The fix on Lunar is both patches; clean cherry-picks.

   * The fix on Mantic is both patches too,
 now in v6.5-rc3, which should be automatically incorporated
 as Mantic apparently will release with the 6.5 kernel [3]

     [1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
     [2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
     [3] 
https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release

  Original Description:
  ---

  losetup fails with devices created manually by mknod on kernel
  5.15.0-69-generic

  # fallocate -l 1G test
  # mknod -m 660 /dev/loop8 b 7 8
  # chown root:disk /dev/loop8
  # losetup /dev/loop8 ./test
  losetup: ./test: failed to set up loop device: Device or resource busy

  Possibly as a result of this patch:
  
https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/

  which was introduced in 5.15.0-68:
  
http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz

  On a machine prior to this change (no issue with losetup):
  # cat /sys/module/loop/parameters/max_loop
  0
  # uname -r
  5.15.0-58-generic

  On a machine after the change (has losetup issue as described above):
  # cat /sys/module/loop/parameters/max_loop
  8
  # uname -r
  5.15.0-69-generic

  So it looks like the default changed and the max amount of loop
  devices that can be created with mknod (not loop-control) is 8. If we
  set max_loop=0 on the kernel command line, it works as before. Cannot
  unload and reload module on a running system to change the parameter
  because it is built into the kernel.

  Another workaround is to use `losetup --find` but that means you
  cannot create with named devices created with mknod.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : 

[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified

[Mauricio Faria de Oliveira]

The kernel changes are Fix Committed in the Azure kernel packages,
and should land slightly earlier than the Generic kernel packages.

linux-azure (5.15.0-1043.50) jammy-proposed
linux-azure-5.15 (5.15.0-1043.50~20.04.1) focal-proposed

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

Title:
  kdump fails on big arm64 systems when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in kexec-tools source package in Focal:
  Fix Released
Status in linux source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in kexec-tools source package in Jammy:
  Fix Released
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
  Invalid
Status in kexec-tools source package in Lunar:
  Fix Released
Status in kexec-tools source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.

  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel region.

  [Fix]

  To address this issue the following upstream commits are needed:

  - From the kernel side:

  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800

  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones

  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800

  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified

  - From kexec-tools:

  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800

  arm64: support more than one crash kernel regions

  Affected releases:
  Jammy, Focal, Bionic

  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.

  [Test Plan]

  You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump, configure the crash kernel size, and trigger a crash.

  1) Failing scenario (crashkernel >= 4G, without offset "@"):

  It won't work unless the offset is specified because the memory
  crashkernel cannot be allocated.

  With the patches applied it works as expected without having to
  specify the offset.

  2) Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G')

  This must continue to work with the new patches (ie, no regressions),
  including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
  Focal).

  [Regression Potential]

  KERNEL 5.15 - Jammy (and Focal via the HWE kernel):

  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.

  kexec-tools - FOCAL:

  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code without altering current functionality.
  Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive 
it moves the code from vmcore-dmesg.c  to elf_info.c so it can be used by other 
features.

  kexec-tools - JAMMY, LUNAR, MANTIC:

  Commit b5a34a20984c is pulled in, it cherry-picks. It changes only
  arm64 code. It enables kexec to recognise that the reserved kernel may
  use more than one kernel region. Things could go worng when gatherinng
  a crashdump.

  [Other]

  Commits to backport

  - MANTIC:

  kernel 

[Kernel-packages] [Bug 2015400] Re: losetup with mknod fails on jammy with kernel 5.15.0-69-generic

[Mauricio Faria de Oliveira]

[J/L][PATCH 0/2] loop: fix regression from max_loop default value change
https://lists.ubuntu.com/archives/kernel-team/2023-July/141350.html

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

Title:
  losetup with mknod fails on jammy with kernel 5.15.0-69-generic

Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  Invalid
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in linux source package in Lunar:
  In Progress
Status in linux-hwe-5.15 source package in Lunar:
  Invalid
Status in linux source package in Mantic:
  Invalid
Status in linux-hwe-5.15 source package in Mantic:
  Invalid

Bug description:
  [ Impact ]

   * Regression in the loop block driver in Jammy kernel
     between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
     due to a change in the default behavior (value) of
     kernel parameter `max_loop` (from 0 to 8) in commit:
     `loop: Fix the max_loop commandline argument treatment
     when it is set to 0` (comment #6).

   * Users of loop devices (major 7) with minor >= 8 now
     fail to `open()` a loop device created with `mknod()`.

   * This is a corner case, as most people use `losetup`
     with usual /dev/loopNUMBER (or `--find`) which are
     not affected as it uses a different code path.
     (`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)

   * Workaround: kernel parameter `max_loop=0`.

  [ Test Steps ]

   * Run the test cases (losetup and test-loop.c in comment #6):
     - max_loop not set (default)
     - max_loop=0
     - max_loop=8

   * Verify the default behavior (max_loop not set) is restored.

   * Verify the modified behavior (max_loop is set) is unchanged.

  [ Regression Potential ]

   * Regressions would be limited to the loop block driver,
     more specifically its default behavior (but it's that now)
     or specific usage of max_loop parameter (tested; looks OK).

  [ Other Info ]

   * The fix on Jammy is just a Revert, since it had not been
     released with the offending patch.

   * The fix on Lunar is the recently accepted 2 patches [1, 2]
     as it was released with the offending patch, so let's keep
     that patch's improvement/behavior for the max_loop=0 case,
     and "fix"/restore the historical no-limit default behavior.

   * The fix on Mantic is the recently accepted 2 patches too,
     now in v6.5-rc3, which should be automatically incorporated
     as Mantic apparently will release with the 6.5 kernel [3]

   * Patch 1 [1] is not quite a fix, but adds CONFIG guards that
     Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
     with that could be done, but Patch 1 seems trivial enough.)

     [1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
     [2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
     [3] 
https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release

  Original Description:
  ---

  losetup fails with devices created manually by mknod on kernel
  5.15.0-69-generic

  # fallocate -l 1G test
  # mknod -m 660 /dev/loop8 b 7 8
  # chown root:disk /dev/loop8
  # losetup /dev/loop8 ./test
  losetup: ./test: failed to set up loop device: Device or resource busy

  Possibly as a result of this patch:
  
https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/

  which was introduced in 5.15.0-68:
  
http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz

  On a machine prior to this change (no issue with losetup):
  # cat /sys/module/loop/parameters/max_loop
  0
  # uname -r
  5.15.0-58-generic

  On a machine after the change (has losetup issue as described above):
  # cat /sys/module/loop/parameters/max_loop
  8
  # uname -r
  5.15.0-69-generic

  So it looks like the default changed and the max amount of loop
  devices that can be created with mknod (not loop-control) is 8. If we
  set max_loop=0 on the kernel command line, it works as before. Cannot
  unload and reload module on a running system to change the parameter
  because it is built into the kernel.

  Another workaround is to use `losetup --find` but that means you
  cannot create with named devices created with mknod.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+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

[Kernel-packages] [Bug 2015400] Re: losetup with mknod fails on jammy with kernel 5.15.0-69-generic

[Mauricio Faria de Oliveira]

Testing on Lunar:
---

The default behavior before the regression is restored/fixed.
The modified behaviors are unchanged.


$ lsb_release -cs
No LSB modules are available.
lunar

Original:

$ uname -rv
6.2.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Wed Jul 12 22:39:51 UTC 
2023

$ cat /proc/cmdline
... root=... ro

$ sudo ./test-loop
open: /dev/loop8: No such device or address

...

$ cat /proc/cmdline
... root=... ro max_loop=0

$ sudo ./test-loop
$

...

$ cat /proc/cmdline
... root=... ro max_loop=8

$ sudo ./test-loop
open: /dev/loop8: No such device or address

Patched:

$ uname -rv
6.2.0-27-generic #28+lp2015400 SMP PREEMPT_DYNAMIC Mon Jul 24 22:16:20 
UTC 2023

$ cat /proc/cmdline
... root=... ro

$ sudo ./test-loop
$

...

$ cat /proc/cmdline
... root=... ro max_loop=0

$ sudo ./test-loop
$

...

$ cat /proc/cmdline
... root=... ro max_loop=8

$ sudo ./test-loop
open: /dev/loop8: No such device or address

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

Title:
  losetup with mknod fails on jammy with kernel 5.15.0-69-generic

Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  Invalid
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in linux source package in Lunar:
  In Progress
Status in linux-hwe-5.15 source package in Lunar:
  Invalid
Status in linux source package in Mantic:
  Invalid
Status in linux-hwe-5.15 source package in Mantic:
  Invalid

Bug description:
  [ Impact ]

   * Regression in the loop block driver in Jammy kernel
     between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
     due to a change in the default behavior (value) of
     kernel parameter `max_loop` (from 0 to 8) in commit:
     `loop: Fix the max_loop commandline argument treatment
     when it is set to 0` (comment #6).

   * Users of loop devices (major 7) with minor >= 8 now
     fail to `open()` a loop device created with `mknod()`.

   * This is a corner case, as most people use `losetup`
     with usual /dev/loopNUMBER (or `--find`) which are
     not affected as it uses a different code path.
     (`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)

   * Workaround: kernel parameter `max_loop=0`.

  [ Test Steps ]

   * Run the test cases (losetup and test-loop.c in comment #6):
     - max_loop not set (default)
     - max_loop=0
     - max_loop=8

   * Verify the default behavior (max_loop not set) is restored.

   * Verify the modified behavior (max_loop is set) is unchanged.

  [ Regression Potential ]

   * Regressions would be limited to the loop block driver,
     more specifically its default behavior (but it's that now)
     or specific usage of max_loop parameter (tested; looks OK).

  [ Other Info ]

   * The fix on Jammy is just a Revert, since it had not been
     released with the offending patch.

   * The fix on Lunar is the recently accepted 2 patches [1, 2]
     as it was released with the offending patch, so let's keep
     that patch's improvement/behavior for the max_loop=0 case,
     and "fix"/restore the historical no-limit default behavior.

   * The fix on Mantic is the recently accepted 2 patches too,
     now in v6.5-rc3, which should be automatically incorporated
     as Mantic apparently will release with the 6.5 kernel [3]

   * Patch 1 [1] is not quite a fix, but adds CONFIG guards that
     Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
     with that could be done, but Patch 1 seems trivial enough.)

     [1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
     [2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
     [3] 
https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release

  Original Description:
  ---

  losetup fails with devices created manually by mknod on kernel
  5.15.0-69-generic

  # fallocate -l 1G test
  # mknod -m 660 /dev/loop8 b 7 8
  # chown root:disk /dev/loop8
  # losetup /dev/loop8 ./test
  losetup: ./test: failed to set up loop device: Device or resource busy

  Possibly as a result of this patch:
  
https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/

  which was introduced in 5.15.0-68:
  
http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz

  On a machine prior to this change (no issue with losetup):
  # cat 

[Kernel-packages] [Bug 2015400] Re: losetup with mknod fails on jammy with kernel 5.15.0-69-generic

[Mauricio Faria de Oliveira]

Testing on Jammy:
---

The default behavior before the regression is restored/fixed.
The modified behaviors are unchanged.

$ lsb_release -cs
jammy

Original:

$ uname -rv
5.15.0-79-generic #86-Ubuntu SMP Mon Jul 10 16:07:21 UTC 2023

$ cat /proc/cmdline
... root=... ro

$ sudo ./test-loop
open: /dev/loop8: No such device or address

...

$ cat /proc/cmdline
... root=... ro max_loop=0

$ sudo ./test-loop
$

...

$ cat /proc/cmdline
... root=... ro max_loop=8

$ sudo ./test-loop
open: /dev/loop8: No such device or address

Patched:
...

$ uname -rv
5.15.0-79-generic #86+lp2015400 SMP Mon Jul 24 21:46:01 UTC 2023


$ cat /proc/cmdline
... root=... ro

$ sudo ./test-loop
$

...


$ cat /proc/cmdline
... root=... ro max_loop=0

$ sudo ./test-loop
$

...

$ cat /proc/cmdline
... root=... ro max_loop=8

$ sudo ./test-loop
open: /dev/loop8: No such device or address

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

Title:
  losetup with mknod fails on jammy with kernel 5.15.0-69-generic

Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  Invalid
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in linux source package in Lunar:
  In Progress
Status in linux-hwe-5.15 source package in Lunar:
  Invalid
Status in linux source package in Mantic:
  Invalid
Status in linux-hwe-5.15 source package in Mantic:
  Invalid

Bug description:
  [ Impact ]

   * Regression in the loop block driver in Jammy kernel
     between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
     due to a change in the default behavior (value) of
     kernel parameter `max_loop` (from 0 to 8) in commit:
     `loop: Fix the max_loop commandline argument treatment
     when it is set to 0` (comment #6).

   * Users of loop devices (major 7) with minor >= 8 now
     fail to `open()` a loop device created with `mknod()`.

   * This is a corner case, as most people use `losetup`
     with usual /dev/loopNUMBER (or `--find`) which are
     not affected as it uses a different code path.
     (`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)

   * Workaround: kernel parameter `max_loop=0`.

  [ Test Steps ]

   * Run the test cases (losetup and test-loop.c in comment #6):
     - max_loop not set (default)
     - max_loop=0
     - max_loop=8

   * Verify the default behavior (max_loop not set) is restored.

   * Verify the modified behavior (max_loop is set) is unchanged.

  [ Regression Potential ]

   * Regressions would be limited to the loop block driver,
     more specifically its default behavior (but it's that now)
     or specific usage of max_loop parameter (tested; looks OK).

  [ Other Info ]

   * The fix on Jammy is just a Revert, since it had not been
     released with the offending patch.

   * The fix on Lunar is the recently accepted 2 patches [1, 2]
     as it was released with the offending patch, so let's keep
     that patch's improvement/behavior for the max_loop=0 case,
     and "fix"/restore the historical no-limit default behavior.

   * The fix on Mantic is the recently accepted 2 patches too,
     now in v6.5-rc3, which should be automatically incorporated
     as Mantic apparently will release with the 6.5 kernel [3]

   * Patch 1 [1] is not quite a fix, but adds CONFIG guards that
     Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
     with that could be done, but Patch 1 seems trivial enough.)

     [1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
     [2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
     [3] 
https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release

  Original Description:
  ---

  losetup fails with devices created manually by mknod on kernel
  5.15.0-69-generic

  # fallocate -l 1G test
  # mknod -m 660 /dev/loop8 b 7 8
  # chown root:disk /dev/loop8
  # losetup /dev/loop8 ./test
  losetup: ./test: failed to set up loop device: Device or resource busy

  Possibly as a result of this patch:
  
https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/

  which was introduced in 5.15.0-68:
  
http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz

  On a machine prior to this change (no issue with losetup):
  # cat /sys/module/loop/parameters/max_loop
  0
  # uname -r
  5.15.0-58-generic

  On a 

[Kernel-packages] [Bug 2015400] Re: losetup with mknod fails on jammy with kernel 5.15.0-69-generic

[Mauricio Faria de Oliveira]

nother workaround is to use `losetup --find` but that means you cannot
  create with named devices created with mknod.

** Also affects: linux (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: linux-hwe-5.15 (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Mantic)
   Importance: Medium
 Assignee: Mauricio Faria de Oliveira (mfo)
   Status: In Progress

** Also affects: linux-hwe-5.15 (Ubuntu Mantic)
   Importance: Undecided
   Status: Invalid

** Also affects: linux (Ubuntu Lunar)
   Importance: Undecided
   Status: New

** Also affects: linux-hwe-5.15 (Ubuntu Lunar)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: linux (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Jammy)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: linux (Ubuntu Lunar)
   Status: New => In Progress

** Changed in: linux (Ubuntu Lunar)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Lunar)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: linux (Ubuntu Mantic)
   Status: In Progress => Invalid

** Changed in: linux (Ubuntu Mantic)
   Importance: Medium => Undecided

** Changed in: linux (Ubuntu Mantic)
 Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned)

** Changed in: linux-hwe-5.15 (Ubuntu Lunar)
   Status: New => Invalid

** Changed in: linux-hwe-5.15 (Ubuntu Jammy)
   Status: New => Invalid

** Also affects: linux (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: linux-hwe-5.15 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Focal)
   Status: New => Invalid

** Changed in: linux-hwe-5.15 (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: linux-hwe-5.15 (Ubuntu Focal)
   Status: New => In Progress

** Changed in: linux-hwe-5.15 (Ubuntu Focal)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Description changed:

  [ Impact ]
  
-  * Regression in the loop block driver in Jammy kernel
-between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
-due to a change in the default behavior (value) of
-kernel parameter `max_loop` (from 0 to 8) in commit:
-`loop: Fix the max_loop commandline argument treatment 
-when it is set to 0` (comment #6).
-
-  * Users of loop devices (major 7) with minor >= 8 now
-fail to `open()` a loop device created with `mknod()`.
-
-  * This is a corner case, as most people use `losetup`
-with usual /dev/loopNUMBER (or `--find`) which are
-not affected as it uses a different code path.
-(`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)
+  * Regression in the loop block driver in Jammy kernel
+    between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
+    due to a change in the default behavior (value) of
+    kernel parameter `max_loop` (from 0 to 8) in commit:
+    `loop: Fix the max_loop commandline argument treatment
+    when it is set to 0` (comment #6).
+ 
+  * Users of loop devices (major 7) with minor >= 8 now
+    fail to `open()` a loop device created with `mknod()`.
+ 
+  * This is a corner case, as most people use `losetup`
+    with usual /dev/loopNUMBER (or `--find`) which are
+    not affected as it uses a different code path.
+    (`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)
+ 
+  * Workaround: kernel parameter `max_loop=0`.
  
  [ Test Steps ]
  
-  * Run the test cases (losetup and test-loop.c in comment #6):
-- max_loop not set (default)
-- max_loop=0
-- max_loop=8
+  * Run the test cases (losetup and test-loop.c in comment #6):
+    - max_loop not set (default)
+    - max_loop=0
+    - max_loop=8
  
-  * Verify the default behavior (max_loop not set) is restored.
-  
-  * Verify the modified behavior (max_loop is set) is unchanged.
-  
+  * Verify the default behavior (max_loop not set) is restored.
+ 
+  * Verify the modified behavior (max_loop is set) is unchanged.
+ 
  [ Regression Potential ]
  
-  * Regressions would be limited to the loop block driver,
-more specifically its default behavior (but it's that now)
-or specific usage of max_loop parameter (tested; looks OK).
-
+  * Regressions would be limited to the loop block driver,
+    more specifically its default behavior (but it's that now)
+    or specific usage of max_loop parameter (tested; looks OK).
+ 
  [ Other Info ]
  
-  * The fix on Jammy is just a Revert, since it had not been
-released with the offending patch.
-
-  * The fix on Lunar is the recently accepted 2 patches [1, 2]
-as it was released with the offending patch, so let's keep
-that patch's improvement/behavior for the max_loop=0 case,
-and "fix"/restore the historical no-limit default behavior.
-
-  * The f

[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified

[Mauricio Faria de Oliveira]

For documentation purposes: the riscv64 build fails on jammy/lunar-proposed,
which is not a regression; that is since/on the jammy/lunar-release pockets.

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

Title:
  kdump fails on big arm64 systems when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in kexec-tools source package in Focal:
  In Progress
Status in linux source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in kexec-tools source package in Jammy:
  Fix Committed
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
  Invalid
Status in kexec-tools source package in Lunar:
  Fix Committed
Status in kexec-tools source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.

  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel region.

  [Fix]

  To address this issue the following upstream commits are needed:

  - From the kernel side:

  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800

  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones

  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800

  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified

  - From kexec-tools:

  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800

  arm64: support more than one crash kernel regions

  Affected releases:
  Jammy, Focal, Bionic

  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.

  [Test Plan]

  You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump, configure the crash kernel size, and trigger a crash.

  - Failing scenario (crashkernel >= 4G, without offset "@"):

  It won't work unless the offset is specified because the memory
  crashkernel cannot be allocated.

  With the patches applied it works as expected without having to
  specify the offset.

  - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G')

  This must continue to work with the new patches (ie, no regressions),
  including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
  Focal).

  [Regression Potential]

  KERNEL 5.15 - Jammy (and Focal via the HWE kernel):

  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.

  kexec-tools - FOCAL:

  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code without altering current functionality.
  Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive 
it moves the code from vmcore-dmesg.c  to elf_info.c so it can be used by other 
features.

  kexec-tools - JAMMY, LUNAR, MANTIC:

  Commit b5a34a20984c is pulled in, it cherry-picks. It changes only
  arm64 code. It enables kexec to recognise that the reserved kernel may
  use more than one kernel region. Things could go worng when gatherinng
  a crashdump.

  [Other]

  Commits to backport

  - MANTIC:

  kernel 6.3: not affected

  kexec-tools:
  b5a34a20984c4ad27cc5054d9957af8130b42a50 

[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified

[Mauricio Faria de Oliveira]

** Changed in: kexec-tools (Ubuntu Focal)
   Status: Incomplete => In Progress

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

Title:
  kdump fails on big arm64 systems when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in kexec-tools source package in Focal:
  In Progress
Status in linux source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in kexec-tools source package in Jammy:
  Fix Committed
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
  Invalid
Status in kexec-tools source package in Lunar:
  Fix Committed
Status in kexec-tools source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.

  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel region.

  [Fix]

  To address this issue the following upstream commits are needed:

  - From the kernel side:

  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800

  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones

  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800

  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified

  - From kexec-tools:

  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800

  arm64: support more than one crash kernel regions

  Affected releases:
  Jammy, Focal, Bionic

  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.

  [Test Plan]

  You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump, configure the crash kernel size, and trigger a crash.

  - Failing scenario (crashkernel >= 4G, without offset "@"):

  It won't work unless the offset is specified because the memory
  crashkernel cannot be allocated.

  With the patches applied it works as expected without having to
  specify the offset.

  - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G')

  This must continue to work with the new patches (ie, no regressions),
  including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
  Focal).

  [Regression Potential]

  KERNEL 5.15 - Jammy (and Focal via the HWE kernel):

  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.

  kexec-tools - FOCAL:

  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code without altering current functionality.
  Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive 
it moves the code from vmcore-dmesg.c  to elf_info.c so it can be used by other 
features.

  kexec-tools - JAMMY, LUNAR, MANTIC:

  Commit b5a34a20984c is pulled in, it cherry-picks. It changes only
  arm64 code. It enables kexec to recognise that the reserved kernel may
  use more than one kernel region. Things could go worng when gatherinng
  a crashdump.

  [Other]

  Commits to backport

  - MANTIC:

  kernel 6.3: not affected

  kexec-tools:
  b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one 
crash kernel regions

  - LUNAR:

  

[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified

[Mauricio Faria de Oliveira]

Hi Steve,

Thanks for reviewing!

> Is this driven by user demand on focal?

Yes, this is driven by a support case from Azure 
(kdump error on Arm64 VM w/ 48 vCPUs 192 GiB RAM).

> Was this a problem in practice when focal was released,
> or has it become a problem more recently 

It seems that support for arm64 on Azure started on 2022,
~2 years after Focal release, as the first arm64 build of
the linux-azure kernel package is 5.4.0-1075.78 (Apr 2022).

https://launchpad.net/ubuntu/focal/+source/linux-azure
https://launchpad.net/ubuntu/+source/linux-azure/5.4.0-1074.77 (amd64 only)
https://launchpad.net/ubuntu/+source/linux-azure/5.4.0-1075.78 (amd64 and arm64)

> I want to make sure we're not just SRUing it here in an effort to be
"completionist".

That's certainly understandable.

In this case, no; the patches are down to Focal as that 
is the release where the bug/support case were reported,
and would ideally be fixed on, if at all possible.

Hope this helps.
Thanks!

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

Title:
  kdump fails on big arm64 systems when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in kexec-tools source package in Focal:
  In Progress
Status in linux source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in kexec-tools source package in Jammy:
  Fix Committed
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
  Invalid
Status in kexec-tools source package in Lunar:
  Fix Committed
Status in kexec-tools source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.

  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel region.

  [Fix]

  To address this issue the following upstream commits are needed:

  - From the kernel side:

  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800

  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones

  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800

  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified

  - From kexec-tools:

  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800

  arm64: support more than one crash kernel regions

  Affected releases:
  Jammy, Focal, Bionic

  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.

  [Test Plan]

  You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump, configure the crash kernel size, and trigger a crash.

  - Failing scenario (crashkernel >= 4G, without offset "@"):

  It won't work unless the offset is specified because the memory
  crashkernel cannot be allocated.

  With the patches applied it works as expected without having to
  specify the offset.

  - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G')

  This must continue to work with the new patches (ie, no regressions),
  including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
  Focal).

  [Regression Potential]

  KERNEL 5.15 - Jammy (and Focal via the HWE kernel):

  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.

  kexec-tools - FOCAL:

  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all 

[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified

[Mauricio Faria de Oliveira]

Hi Jo,

Thanks for the debdiffs.

Lunar and Jammy (both: 1 patch) look good, just removed '0001' from
.patch.

Focal has 6 patches and required more attention/changes (which I adjusted),
and patches look good (some notes below for documentation/other reviewers).

The (updated) debdiffs built correctly on ppa:mfo/lp2024479 on supported
architectures (amd64, arm64, armhf, ppc64el, s390x) and I'm confident on
your testing to be performed during -proposed verification. 

So, uploaded to F/J/L.

Thanks,
Mauricio

...

Focal:

1) all Origin: links had wrong commit IDs; fixed.

2) there are commits to fix 3 different things, IIUIC,
   all of which are needed for big arm64 systems:
   (patches 1-2) phys_offset on large memory systems;
   (patches 3-5) many memory regions in /proc/iomem;
   (patch 6) split / memory regions for crash kernel;

3) patch 1 is mostly a big code movement, which I followed,
   and the few small changes in existing functions are for
   the purpose described (and are additions, not changes).

4) patch 2 adds code and hooks it into existing code
  
5) patch 3 simplifies the function call path, which is OK,
   and does a more significant logic change, but it still
   should perform the same thing (parse /proc/iomem format,
   which didn't change), and has no fixup commits.

6) patch 4 adds helpers for patches 3 and 5.

7) btw, patches 3/4 order is swapped (3 deps on 4); fixed.

8) patch 5 uses the helpers to change some existing code
   from static to dynamic allocation.

9) patch 6 (added to J/L/M) too, similarly, for the number
   of crash kernel / usable memory regions.
   
Fix-up commits: none strictly required.
---

I checked for newer commits (after 1st) in the modified files:
(cat lp2024479_focal-v2.debdiff | grep '^+--- a/' | cut -d/ -f2- | sort -u)

$ git log --oneline f4ce0706d9574aecb7d4aa9af7208a1bc9b6afb4..origin/master -- \
  kexec/arch/arm64/{kexec,crashdump}-arm64.{c,h} \
  kexec/mem_regions.{c,h} \
  util_lib/Makefile \
  vmcore-dmesg/Makefile \
  vmcore-dmesg/vmcore-dmesg.c

Only 4 commits were applicable to these code changes, AFAICT.

There are 3 cleanup/style/optional, no functional impact:

- commit 545c811050a3 ("Cleanup: remove the read_elf_kcore()")
- commit 14ad054e7baa ("Fix an error definition about the variable 'fname'") 
- commit a7c4cb8e9985 ("Cleanup: move it back from util_lib/elf_info.c")

There is 1 which is more serious, but does not impact Ubuntu kernels,
since do not use 52-bit (but 48-) virtual address space with M/L/J/F:

- commit 67ea2d99e135 ("arm64: make phys_offset signed")
  (... phys_offset can be negative if running 52-bits kernel on 48-bits 
hardware ...)
  
  mantic:
$ git grep -r ARM64_VA_BITS origin/master-next -- debian.master/config 
| grep -e "'y'" -e ARM64_VA_BITS_52
<...>:CONFIG_ARM64_VA_BITS_48 policy<{'arm64': 
'y'}>
<...>:CONFIG_ARM64_VA_BITS_52 
policy<{'arm64-generic-64k': 'n'}>
  lunar:
$ git grep -r ARM64_VA_BITS origin/master-next -- debian.master/config 
| grep -e "'y'" -e ARM64_VA_BITS_52
<...>:CONFIG_ARM64_VA_BITS_48 policy<{'arm64': 
'y'}>
<...>:CONFIG_ARM64_VA_BITS_52 
policy<{'arm64-generic-64k': 'n'}>
  jammy:
$ git grep -r ARM64_VA_BITS origin/master-next -- debian.master/config 
| grep -e "'y'" -e ARM64_VA_BITS_52
<...>:CONFIG_ARM64_VA_BITS_48 policy<{'arm64': 
'y'}>
<...>:CONFIG_ARM64_VA_BITS_52 
policy<{'arm64-generic-64k': 'n', 'arm64-lowlatency-64k': 'n'}>
  focal:
$ git grep -r ARM64_VA_BITS origin/master-next -- debian.master/config 
| grep -e "'y'" -e ARM64_VA_BITS_52
<...>:CONFIG_ARM64_VA_BITS_48 policy<{'arm64': 
'y'}>

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

Title:
  kdump fails on big arm64 systems when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in kexec-tools source package in Focal:
  In Progress
Status in linux source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in kexec-tools source package in Jammy:
  In Progress
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
  Invalid
Status in kexec-tools source package in Lunar:
  In Progress
Status in kexec-tools source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  kdump fails on arm64, on machines with a lot of memory when offset is not 

[Kernel-packages] [Bug 2024479] Re: kdump fails on big arm64 systems when offset is not specified

[Mauricio Faria de Oliveira]

** Summary changed:

- kdump fails on arm64 when offset is not specified
+ kdump fails on big arm64 systems when offset is not specified

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

Title:
  kdump fails on big arm64 systems when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in kexec-tools source package in Focal:
  In Progress
Status in linux source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in kexec-tools source package in Jammy:
  In Progress
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
  Invalid
Status in kexec-tools source package in Lunar:
  In Progress
Status in kexec-tools source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.

  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel region.

  [Fix]

  To address this issue the following upstream commits are needed:

  - From the kernel side:

  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800

  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones

  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800

  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified

  - From kexec-tools:

  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800

  arm64: support more than one crash kernel regions

  Affected releases:
  Jammy, Focal, Bionic

  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.

  [Test Plan]

  You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump, configure the crash kernel size, and trigger a crash.

  - Failing scenario (crashkernel >= 4G, without offset "@"):

  It won't work unless the offset is specified because the memory
  crashkernel cannot be allocated.

  With the patches applied it works as expected without having to
  specify the offset.

  - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G')

  This must continue to work with the new patches (ie, no regressions),
  including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
  Focal).

  [Regression Potential]

  KERNEL 5.15 - Jammy (and Focal via the HWE kernel):

  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.

  kexec-tools - FOCAL:

  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code without altering current functionality.
  Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive 
it moves the code from vmcore-dmesg.c  to elf_info.c so it can be used by other 
features.

  kexec-tools - JAMMY, LUNAR, MANTIC:

  Commit b5a34a20984c is pulled in, it cherry-picks. It changes only
  arm64 code. It enables kexec to recognise that the reserved kernel may
  use more than one kernel region. Things could go worng when gatherinng
  a crashdump.

  [Other]

  Commits to backport

  - MANTIC:

  kernel 6.3: not affected

  kexec-tools:
  b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more 

[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified

[Mauricio Faria de Oliveira]

Ioanna and I just discussed about the working scenario (eg, crashkernel=1G on 
5.4 kernel),
for it to be verified/no regressions with the patches (patched kexec-tools on 
5.4 kernel).

This apparently isn't an issue, as the patch in J/L mentions it is backward 
compatible
(still going through the other patches in F), but that should, sure, be double 
checked.

Updated the Test Plan section accordingly.

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

Title:
  kdump fails on arm64 when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in kexec-tools source package in Focal:
  In Progress
Status in linux source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in kexec-tools source package in Jammy:
  In Progress
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in linux-hwe-5.15 source package in Kinetic:
  Invalid
Status in kexec-tools source package in Lunar:
  In Progress
Status in kexec-tools source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.

  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel region.

  [Fix]

  To address this issue the following upstream commits are needed:

  - From the kernel side:

  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800

  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones

  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800

  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified

  - From kexec-tools:

  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800

  arm64: support more than one crash kernel regions

  Affected releases:
  Jammy, Focal, Bionic

  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.

  [Test Plan]

  You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump, configure the crash kernel size, and trigger a crash.

  - Failing scenario (crashkernel >= 4G, without offset "@"):

  It won't work unless the offset is specified because the memory
  crashkernel cannot be allocated.

  With the patches applied it works as expected without having to
  specify the offset.

  - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G')

  This must continue to work with the new patches (ie, no regressions),
  including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
  Focal).

  [Regression Potential]

  KERNEL 5.15 - Jammy (and Focal via the HWE kernel):

  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.

  kexec-tools - FOCAL:

  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code without altering current functionality.
  Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive 
it moves the code from vmcore-dmesg.c  to elf_info.c so it can be used by other 
features.

  kexec-tools - JAMMY, LUNAR, MANTIC:

  Commit b5a34a20984c is pulled in, it cherry-picks. It changes only
  arm64 code. It enables kexec to recognise that the reserved kernel may

[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified

[Mauricio Faria de Oliveira]

** Description changed:

  [Impact]
  
  kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"
  
  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.
  
  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel region.
  
  [Fix]
  
  To address this issue the following upstream commits are needed:
  
  - From the kernel side:
  
  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800
  
  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones
  
  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800
  
  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified
  
  - From kexec-tools:
  
  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800
  
  arm64: support more than one crash kernel regions
  
  Affected releases:
  Jammy, Focal, Bionic
  
  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.
  
  [Test Plan]
  
  You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
- Install linux-crashdump and trigger a crash.
- It won't work unless the offset is specified because the memory crashkernel 
cannot be allocated.
+ Install linux-crashdump, configure the crash kernel size, and trigger a crash.
+ 
+ - Failing scenario (crashkernel >= 4G, without offset "@"):
+ 
+ It won't work unless the offset is specified because the memory
+ crashkernel cannot be allocated.
  
  With the patches applied it works as expected without having to specify
  the offset.
+ 
+ - Working scenario (crashkernel < 4G, e.g., 'crashkernel=1G')
+ 
+ This must continue to work with the new patches (ie, no regressions),
+ including patched kexec-tools on unpatched kernel (eg, 5.4 kernel on
+ Focal).
  
  [Regression Potential]
  
  KERNEL 5.15 - Jammy (and Focal via the HWE kernel):
  
  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.
  
  kexec-tools - FOCAL:
  
  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code without altering current functionality.
  Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive 
it moves the code from vmcore-dmesg.c  to elf_info.c so it can be used by other 
features.
  
  kexec-tools - JAMMY, LUNAR, MANTIC:
  
  Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64
  code. It enables kexec to recognise that the reserved kernel may use
  more than one kernel region. Things could go worng when gatherinng a
  crashdump.
  
  [Other]
  
  Commits to backport
  
  - MANTIC:
  
  kernel 6.3: not affected
  
  kexec-tools:
  b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one 
crash kernel regions
  
  - LUNAR:
  
  kernel 6.2: not affected
  
  kexec-tools:
  b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one 
crash kernel regions
  
  - KINETIC: WON'T FIX
  
  Kinetic won't be fixed as it is EOL soon.
  
  - JAMMY:
  
  kernel (5.15 kernel):
  
  a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support 
crashkernel=X fall back to reserve region above DMA zones
  a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default 
size when crashkernel=Y,low is not specified
  4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define 
defer_reserve_crashkernel()
  8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64: kdump: Do not allocate 
crash low memory if not needed
  5832f1ae50600ac6b2b6d00cfef42d33a9473f06 docs: kdump: Update the 
crashkernel description for arm64
  944a45abfabc171fd121315ff0d5e62b11cb5d6f arm64: kdump: Reimplement 
crashkernel=X
  

[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified

[Mauricio Faria de Oliveira]

** Description changed:

- [Description]
+ [Impact]
  
- kdump fails on arm64, on machines with a lot of memory when offeset is not 
specified,
+ kdump fails on arm64, on machines with a lot of memory when offset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"
  
  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.
  
  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
- In addition kexec-tools needs to support more than one crash kernel regions.
+ In addition kexec-tools needs to support more than one crash kernel region.
  
  [Fix]
  
- To address this issue the following upstrem commits are needed:
+ To address this issue the following upstream commits are needed:
  
  - From the kernel side:
  
- commit a9ae89df737756d92f0e14873339cf393f7f7eb0
- Author: Zhen Lei 
- Date: Wed Nov 16 20:10:44 2022 +0800
+ commit a9ae89df737756d92f0e14873339cf393f7f7eb0
+ Author: Zhen Lei 
+ Date: Wed Nov 16 20:10:44 2022 +0800
  
- arm64: kdump: Support crashkernel=X fall back to reserve region
+ arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones
  
- commit a149cf00b158e1793a8dd89ca492379c366300d2
- Author: Zhen Lei 
- Date: Wed Nov 16 20:10:43 2022 +0800
+ commit a149cf00b158e1793a8dd89ca492379c366300d2
+ Author: Zhen Lei 
+ Date: Wed Nov 16 20:10:43 2022 +0800
  
- arm64: kdump: Provide default size when crashkernel=Y,low is not
+ arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified
  
  - From kexec-tools:
  
- commit b5a34a20984c4ad27cc5054d9957af8130b42a50
- Author: Chen Zhou 
- Date: Mon Jan 10 18:20:08 2022 +0800
+ commit b5a34a20984c4ad27cc5054d9957af8130b42a50
+ Author: Chen Zhou 
+ Date: Mon Jan 10 18:20:08 2022 +0800
  
- arm64: support more than one crash kernel regions
+ arm64: support more than one crash kernel regions
  
  Affected releases:
  Jammy, Focal, Bionic
  
  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
- Only the 5.15 hwe focal kernel will be fixed.
+ Only the Focal 5.15 hwe kernel (from Jammy) will be fixed.
  
- [Test]
+ [Test Plan]
  
- You need a machine (can be a VM too) with large memory e.g. 128G.
+ You need an arm64 machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump and trigger a crash.
  It won't work unless the offset is specified because the memory crashkernel 
cannot be allocated.
  
  With the patches applied it works as expected without having to specify
  the offset.
  
  [Regression Potential]
  
- KERNEL 5.15:
+ KERNEL 5.15 - Jammy (and Focal via the HWE kernel):
+ 
  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.
  
- KEXEX - FOCAL:
+ kexec-tools - FOCAL:
+ 
  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code without altering current functionality.
  Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive 
it moves the code from vmcore-dmesg.c  to elf_info.c so it can be used by other 
features.
  
- KEXEC - JAMMY, LUNAR, MANTIC:
- Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 
code. It enables kexec to recognise that teh reserved kernel may use more than 
one kernel region. Things could go worng when gatherinng a crashdump.
+ kexec-tools - JAMMY, LUNAR, MANTIC:
+ 
+ Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64
+ code. It enables kexec to recognise that the reserved kernel may use
+ more than one kernel region. Things could go worng when gatherinng a
+ crashdump.
  
  [Other]
  
  Commits to backport
  
  - MANTIC:
  
- kernel 6.3: not affected
+ kernel 6.3: not affected
  
- kexec-tools:
- b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one 
crash kernel regions
+ kexec-tools:
+ b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one 
crash kernel regions
  
  - LUNAR:
  
- kernel 6.2: not 

[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified

[Mauricio Faria de Oliveira]

Hey Christian, thanks for the quick review and sponsorship.

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

Title:
  kdump fails on arm64 when offset is not specified

Status in kexec-tools package in Ubuntu:
  Fix Committed
Status in linux package in Ubuntu:
  Incomplete
Status in kexec-tools source package in Focal:
  In Progress
Status in linux source package in Focal:
  Won't Fix
Status in kexec-tools source package in Jammy:
  In Progress
Status in linux source package in Jammy:
  Incomplete
Status in kexec-tools source package in Kinetic:
  Won't Fix
Status in linux source package in Kinetic:
  Won't Fix
Status in kexec-tools source package in Lunar:
  In Progress
Status in kexec-tools source package in Mantic:
  Fix Committed

Bug description:
  [Description]

  kdump fails on arm64, on machines with a lot of memory when offeset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.

  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel regions.

  [Fix]

  To address this issue the following upstrem commits are needed:

  - From the kernel side:

  commit a9ae89df737756d92f0e14873339cf393f7f7eb0
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:44 2022 +0800

  arm64: kdump: Support crashkernel=X fall back to reserve region
  above DMA zones

  commit a149cf00b158e1793a8dd89ca492379c366300d2
  Author: Zhen Lei 
  Date: Wed Nov 16 20:10:43 2022 +0800

  arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified

  - From kexec-tools:

  commit b5a34a20984c4ad27cc5054d9957af8130b42a50
  Author: Chen Zhou 
  Date: Mon Jan 10 18:20:08 2022 +0800

  arm64: support more than one crash kernel regions

  Affected releases:
  Jammy, Focal, Bionic

  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the 5.15 hwe focal kernel will be fixed.

  [Test]

  You need a machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump and trigger a crash.
  It won't work unless the offset is specified because the memory crashkernel 
cannot be allocated.

  With the patches applied it works as expected without having to
  specify the offset.

  [Regression Potential]

  KERNEL 5.15:
  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.

  KEXEX - FOCAL:
  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code without altering current functionality.
  Commit f4ce0706d9574aecb7 adds functionality to read elf notes. In practive 
it moves the code from vmcore-dmesg.c  to elf_info.c so it can be used by other 
features.

  KEXEC - JAMMY, LUNAR, MANTIC:
  Commit b5a34a20984c is pulled in, it cherry-picks. It changes only arm64 
code. It enables kexec to recognise that teh reserved kernel may use more than 
one kernel region. Things could go worng when gatherinng a crashdump.

  [Other]

  Commits to backport

  - MANTIC:

  kernel 6.3: not affected

  kexec-tools:
  b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one 
crash kernel regions

  - LUNAR:

  kernel 6.2: not affected

  kexec-tools:
  b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one 
crash kernel regions

  - KINETIC: WON'T FIX

  Kinetic won't be fixed as it EOLs soon.

  - JAMMY:

  kernel (5.15 kernel):

  a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support 
crashkernel=X fall back to reserve region above DMA zones
  a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default 
size when crashkernel=Y,low is not specified
  4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define 
defer_reserve_crashkernel()
  8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64: kdump: Do not 

[Kernel-packages] [Bug 2024479] Re: kdump fails on arm64 when offset is not specified

[Mauricio Faria de Oliveira]

Hi Jo,

Thanks for the bug report, sru template, and debdiffs!

For Mantic, we currently do not have sponsors that could upload, but I
certainly can review the debdiff and give you some feedback/request
changes before reaching out to another sponsor/uploader, to hopefully
make their life easier.

For the Mantic debdiff, it's great, thanks -- just some minor points:

1) the patch file name is 0001-*, and when looking at the tail of the
series file, there's already a 0001, and some patches which don't follow
a numbered convention?  So, my suggestion would be to stick to the
'lpNNN-patch-subject.patch' convention, for the file name.

2.1) Nice touch on the DEP-3 headers! For Origin:, I just would like to suggest 
the URL be for the 'commit' page vs. a 'patch' page, which improves readability 
(colors/visual/etc), but note there's no strict requirement on this.
2.2) On Origin: again, if there's any changes for the patch to apply, please 
use the 'backport' keyword instead of 'upstream' (I didn't check, so it might 
be fully correct; but noting it just in case).

(BTW, I could not review the code changes yet.)

Now, on 'finding a sponsor' for Mantic, we can do that for you, or help
you with it, in case you'd like to have the exposure/conversation with
other people involved in the process. (It's totally fine to pick the
former if you're busy or any other reason, this is what we're here for.)

Please confirm which path you'd prefer this time.

Thanks,
Mauricio


** Changed in: kexec-tools (Ubuntu Mantic)
   Status: In Progress => Incomplete

** Tags added: se-sponsor-mfo

** Description changed:

  [Description]
  
  kdump fails on arm64, on machines with a lot of memory when offeset is not 
specified,
  e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"
  
  If kdump-tools.cfg specifies the offset e.g.:
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
  it works ok.
  
  The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
  in low and high memory.
  This is addressed in kernel 6.2.
  In addition kexec-tools needs to support more than one crash kernel regions.
  
+ [Fix]
+ 
  To address this issue the following upstrem commits are needed:
  
- From the kernel side :
- commit a9ae89df737756d92f0e14873339cf393f7f7eb0
- Author: Zhen Lei 
- Date: Wed Nov 16 20:10:44 2022 +0800
+ - From the kernel side:
  
- arm64: kdump: Support crashkernel=X fall back to reserve region above
- DMA zones
+ commit a9ae89df737756d92f0e14873339cf393f7f7eb0
+ Author: Zhen Lei 
+ Date: Wed Nov 16 20:10:44 2022 +0800
  
- commit a149cf00b158e1793a8dd89ca492379c366300d2
- Author: Zhen Lei 
- Date: Wed Nov 16 20:10:43 2022 +0800
+ arm64: kdump: Support crashkernel=X fall back to reserve region
+ above DMA zones
  
- arm64: kdump: Provide default size when crashkernel=Y,low is not
+ commit a149cf00b158e1793a8dd89ca492379c366300d2
+ Author: Zhen Lei 
+ Date: Wed Nov 16 20:10:43 2022 +0800
+ 
+ arm64: kdump: Provide default size when crashkernel=Y,low is not
  specified
  
- From kexec-tools
- commit b5a34a20984c4ad27cc5054d9957af8130b42a50
- Author: Chen Zhou 
- Date: Mon Jan 10 18:20:08 2022 +0800
+ - From kexec-tools:
  
- arm64: support more than one crash kernel regions
+ commit b5a34a20984c4ad27cc5054d9957af8130b42a50
+ Author: Chen Zhou 
+ Date: Mon Jan 10 18:20:08 2022 +0800
+ 
+ arm64: support more than one crash kernel regions
  
  Affected releases:
  Jammy, Focal, Bionic
  
  For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
  The same applies for the Focal 5.4 kernel.
  Only the 5.15 hwe focal kernel will be fixed.
  
  [Test]
  
  You need a machine (can be a VM too) with large memory e.g. 128G.
  Install linux-crashdump and trigger a crash.
  It won't work unless the offset is specified because the memory crashkernel 
cannot be allocated.
  
  With the patches applied it works as expected without having to specify
  the offset.
  
  [Regression Potential]
  
  KERNEL 5.15:
  To address this problem in the 5.15 kernel we need to pull in 7 commits (see 
[Other] section for details.
  All the commits are changing code only for arm64 architecture and only the 
code related to reserving the crashkernel.
  This means that any regression potential will affect only the arm64 
architecture and in particular the crash/kdump functionality.
  However, since the reservation of the crashkernel occurs at boot up, 
potentially things could go wrong there as well.
  
  KEXEX - FOCAL:
  To fix the kexec_tools in focal we need to pull in 6 commits (see [Other 
section for details]). They all cherry pick.
  Four out of six commits touch only arm64 code. Any regression potential 
because of these commits  would regard either crashdump or kexec functionality.
  Commit cf977b1af9ec67fab adds code 

[Kernel-packages] [Bug 2015765] Re: autopkgtests fail with "EE: Missing modules"

[Mauricio Faria de Oliveira]

Apparently, the check for (non-ignored) modules might be inexact? as both 
'mstflint_access' and 'nvidia-fs' are in the linux-modules-*-nvidia deb package.
(Note: this is just a su-guess-tion :) I haven't looked at it.)

$ dpkg-deb -c linux-modules-5.15.0-1017-nvidia_5.15.0-1017.17_amd64.deb | grep 
-i mstflint.access
drwxr-xr-x root/root 0 2023-02-01 00:00 
./lib/modules/5.15.0-1017-nvidia/kernel/mstflint_access/
-rw-r--r-- root/root 46409 2023-02-01 00:00 
./lib/modules/5.15.0-1017-nvidia/kernel/mstflint_access/mstflint_access.ko

$ dpkg-deb -c linux-modules-5.15.0-1018-nvidia_5.15.0-1018.18_amd64.deb | grep 
-i mstflint.access
drwxr-xr-x root/root 0 2023-03-06 17:20 
./lib/modules/5.15.0-1018-nvidia/kernel/mstflint_access/
-rw-r--r-- root/root 46409 2023-03-06 17:20 
./lib/modules/5.15.0-1018-nvidia/kernel/mstflint_access/mstflint_access.ko

$ dpkg-deb -c linux-modules-5.15.0-1017-nvidia_5.15.0-1017.17_amd64.deb | grep 
-i nvidia.fs
drwxr-xr-x root/root 0 2023-02-01 00:00 
./lib/modules/5.15.0-1017-nvidia/kernel/nvidia-fs/
-rw-r--r-- root/root219921 2023-02-01 00:00 
./lib/modules/5.15.0-1017-nvidia/kernel/nvidia-fs/nvidia-fs.ko

$ dpkg-deb -c linux-modules-5.15.0-1018-nvidia_5.15.0-1018.18_amd64.deb | grep 
-i nvidia.fs
drwxr-xr-x root/root 0 2023-03-06 17:20 
./lib/modules/5.15.0-1018-nvidia/kernel/nvidia-fs/
-rw-r--r-- root/root219921 2023-03-06 17:20 
./lib/modules/5.15.0-1018-nvidia/kernel/nvidia-fs/nvidia-fs.ko


** Tags added: update-excuse-jammy

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

Title:
  autopkgtests fail with "EE: Missing modules"

Status in linux-nvidia package in Ubuntu:
  New

Bug description:
  II: Checking modules for nvidia...
  read 12 modules.
 reading new modules...read 6315 modules.
 reading old modules...
MISS: icp (ignored)
MISS: mstflint_access
MISS: nvidia-fs
MISS: spl (ignored)
MISS: v4l2loopback (ignored)
MISS: zavl (ignored)
MISS: zcommon (ignored)
MISS: zfs (ignored)
MISS: zlua (ignored)
MISS: znvpair (ignored)
MISS: zunicode (ignored)
MISS: zzstd (ignored)
NEW: 8250
  ...
NEW: zswap
read 6017 modules : new(310)  missing(12)
  EE: Missing modules
  make: *** [debian/rules.d/4-checks.mk:10: module-check-nvidia] Error 1
  dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2
  autopkgtest [01:49:45]: test rebuild: ---]
  autopkgtest [01:49:45]: test rebuild:  - - - - - - - - - - results - - - - - 
- - - - -
  rebuild  FAIL non-zero exit status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2015765/+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

[Kernel-packages] [Bug 2015765] [NEW] autopkgtests fail with "EE: Missing modules"

[Mauricio Faria de Oliveira]

Public bug reported:

II: Checking modules for nvidia...
read 12 modules.
   reading new modules...read 6315 modules.
   reading old modules...
  MISS: icp (ignored)
  MISS: mstflint_access
  MISS: nvidia-fs
  MISS: spl (ignored)
  MISS: v4l2loopback (ignored)
  MISS: zavl (ignored)
  MISS: zcommon (ignored)
  MISS: zfs (ignored)
  MISS: zlua (ignored)
  MISS: znvpair (ignored)
  MISS: zunicode (ignored)
  MISS: zzstd (ignored)
  NEW: 8250
...
  NEW: zswap
  read 6017 modules : new(310)  missing(12)
EE: Missing modules
make: *** [debian/rules.d/4-checks.mk:10: module-check-nvidia] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2
autopkgtest [01:49:45]: test rebuild: ---]
autopkgtest [01:49:45]: test rebuild:  - - - - - - - - - - results - - - - - - 
- - - -
rebuild  FAIL non-zero exit status 2

** Affects: linux-nvidia (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: update-excuse-jammy

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

Title:
  autopkgtests fail with "EE: Missing modules"

Status in linux-nvidia package in Ubuntu:
  New

Bug description:
  II: Checking modules for nvidia...
  read 12 modules.
 reading new modules...read 6315 modules.
 reading old modules...
MISS: icp (ignored)
MISS: mstflint_access
MISS: nvidia-fs
MISS: spl (ignored)
MISS: v4l2loopback (ignored)
MISS: zavl (ignored)
MISS: zcommon (ignored)
MISS: zfs (ignored)
MISS: zlua (ignored)
MISS: znvpair (ignored)
MISS: zunicode (ignored)
MISS: zzstd (ignored)
NEW: 8250
  ...
NEW: zswap
read 6017 modules : new(310)  missing(12)
  EE: Missing modules
  make: *** [debian/rules.d/4-checks.mk:10: module-check-nvidia] Error 1
  dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2
  autopkgtest [01:49:45]: test rebuild: ---]
  autopkgtest [01:49:45]: test rebuild:  - - - - - - - - - - results - - - - - 
- - - - -
  rebuild  FAIL non-zero exit status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2015765/+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

[Kernel-packages] [Bug 2015400] Re: losetup with mknod fails on jammy with kernel 5.15.0-69-generic

[Mauricio Faria de Oliveira]

Marking linux-hwe-5.15 as Invalid as it follows linux 5.15
(will get the fix automatically from linux 5.15 from jammy).

** Changed in: linux (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: linux-hwe-5.15 (Ubuntu)
   Status: New => Invalid

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

Title:
  losetup with mknod fails on jammy with kernel 5.15.0-69-generic

Status in linux package in Ubuntu:
  In Progress
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid

Bug description:
  losetup fails with devices created manually by mknod on kernel
  5.15.0-69-generic

  # fallocate -l 1G test
  # mknod -m 660 /dev/loop8 b 7 8
  # chown root:disk /dev/loop8
  # losetup /dev/loop8 ./test
  losetup: ./test: failed to set up loop device: Device or resource busy

  Possibly as a result of this patch:
  
https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/

  which was introduced in 5.15.0-68:
  
http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz

  On a machine prior to this change (no issue with losetup):
  # cat /sys/module/loop/parameters/max_loop
  0
  # uname -r
  5.15.0-58-generic

  On a machine after the change (has losetup issue as described above):
  # cat /sys/module/loop/parameters/max_loop
  8
  # uname -r
  5.15.0-69-generic

  So it looks like the default changed and the max amount of loop
  devices that can be created with mknod (not loop-control) is 8. If we
  set max_loop=0 on the kernel command line, it works as before. Cannot
  unload and reload module on a running system to change the parameter
  because it is built into the kernel.

  Another workaround is to use `losetup --find` but that means you
  cannot create with named devices created with mknod.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+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

[Kernel-packages] [Bug 2015400] Re: losetup with mknod fails on jammy with kernel 5.15.0-69-generic

[Mauricio Faria de Oliveira]

** Attachment added: "loop-ctl-add.c"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+attachment/5661724/+files/loop-ctl-add.c

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

Title:
  losetup with mknod fails on jammy with kernel 5.15.0-69-generic

Status in linux package in Ubuntu:
  Confirmed
Status in linux-hwe-5.15 package in Ubuntu:
  New

Bug description:
  losetup fails with devices created manually by mknod on kernel
  5.15.0-69-generic

  # fallocate -l 1G test
  # mknod -m 660 /dev/loop8 b 7 8
  # chown root:disk /dev/loop8
  # losetup /dev/loop8 ./test
  losetup: ./test: failed to set up loop device: Device or resource busy

  Possibly as a result of this patch:
  
https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/

  which was introduced in 5.15.0-68:
  
http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz

  On a machine prior to this change (no issue with losetup):
  # cat /sys/module/loop/parameters/max_loop
  0
  # uname -r
  5.15.0-58-generic

  On a machine after the change (has losetup issue as described above):
  # cat /sys/module/loop/parameters/max_loop
  8
  # uname -r
  5.15.0-69-generic

  So it looks like the default changed and the max amount of loop
  devices that can be created with mknod (not loop-control) is 8. If we
  set max_loop=0 on the kernel command line, it works as before. Cannot
  unload and reload module on a running system to change the parameter
  because it is built into the kernel.

  Another workaround is to use `losetup --find` but that means you
  cannot create with named devices created with mknod.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+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

[Kernel-packages] [Bug 2015400] Re: losetup with mknod fails on jammy with kernel 5.15.0-69-generic

[Mauricio Faria de Oliveira]

Simpler workarounds:

For non-existing /dev/loopN devices, `losetup /dev/loopN image` should
work (i.e., don't do `mknod /dev/loopN`).

For /dev/non-loopN devices, it doesn't (different code path), so the
utility attached should help for now.

Details below.

...

# lsb_release -cs
jammy

# uname -rv
5.15.0-69-generic #76-Ubuntu SMP Fri Mar 17 17:19:29 UTC 2023

# cat /sys/module/loop/parameters/max_loop
8

# ls -1 /dev/loop*
/dev/loop-control
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
/dev/loop6
/dev/loop7

# grep loop /proc/devices
  7 loop

# truncate -s 1g test

Case 1) Existing /dev/loopN: LOOP_CTL_ADD is not called, open() fails (non-init 
mutex, apparently).
  
# mknod /dev/loop8 b 7 8
# strace -e openat,ioctl losetup /dev/loop8 test 2>&1 | grep -i loop
openat(AT_FDCWD, "/dev/loop8", O_RDWR|O_CLOEXEC) = -1 ENXIO (No such device or 
address)
openat(AT_FDCWD, "/dev/loop8", O_RDWR|O_CLOEXEC) = -1 ENXIO (No such device or 
address)
losetup: /dev/loop8: failed to set up loop device

Case 2) Non-existing /dev/loopN: LOOP_CTL_ADD is called, open() works.

# rm /dev/loop8

# strace -e openat,ioctl losetup /dev/loop8 test 2>&1 | grep -i loop
openat(AT_FDCWD, "/dev/loop-control", O_RDWR|O_CLOEXEC) = 3
ioctl(3, LOOP_CTL_ADD, 8)   = 8
openat(AT_FDCWD, "/dev/loop8", O_RDWR|O_CLOEXEC) = 4
ioctl(4, LOOP_CONFIGURE, {fd=3, block_size=0, info={lo_offset=0, lo_number=0, 
lo_flags=0, lo_file_name="/root/test", ...}}) = 0

Case 3) Non-existing /dev/non-loopN: LOOP_CTL_ADD is not called, open()
fails.

# strace -e openat,ioctl losetup /dev/mynameX test 2>&1 | grep -i loop
losetup: /dev/mynameX: failed to set up loop device

Case 4) Existing /dev/non-loopN with workaround tool (attached)

# gcc -o loop-ctl-add loop-ctl-add.c

# mknod /dev/mynameX b 7 42

# losetup /dev/mynameX test
losetup: /dev/mynameX: failed to set up loop device: No such device or address

# ./loop-ctl-add 42
Success on ioctl('/dev/loop-control', LOOP_CTL_ADD, 42)

# losetup /dev/mynameX test
#

works!

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

Title:
  losetup with mknod fails on jammy with kernel 5.15.0-69-generic

Status in linux package in Ubuntu:
  Confirmed
Status in linux-hwe-5.15 package in Ubuntu:
  New

Bug description:
  losetup fails with devices created manually by mknod on kernel
  5.15.0-69-generic

  # fallocate -l 1G test
  # mknod -m 660 /dev/loop8 b 7 8
  # chown root:disk /dev/loop8
  # losetup /dev/loop8 ./test
  losetup: ./test: failed to set up loop device: Device or resource busy

  Possibly as a result of this patch:
  
https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/

  which was introduced in 5.15.0-68:
  
http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz

  On a machine prior to this change (no issue with losetup):
  # cat /sys/module/loop/parameters/max_loop
  0
  # uname -r
  5.15.0-58-generic

  On a machine after the change (has losetup issue as described above):
  # cat /sys/module/loop/parameters/max_loop
  8
  # uname -r
  5.15.0-69-generic

  So it looks like the default changed and the max amount of loop
  devices that can be created with mknod (not loop-control) is 8. If we
  set max_loop=0 on the kernel command line, it works as before. Cannot
  unload and reload module on a running system to change the parameter
  because it is built into the kernel.

  Another workaround is to use `losetup --find` but that means you
  cannot create with named devices created with mknod.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+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

[Kernel-packages] [Bug 2015400] Re: losetup with mknod fails on jammy with kernel 5.15.0-69-generic

[Mauricio Faria de Oliveira]

Possible workaround w/ losetup.

# uname -rv
5.15.0-69-generic #76-Ubuntu SMP Fri Mar 17 17:19:29 UTC 2023

# cat /sys/module/loop/parameters/max_loop
8

# losetup -nl | sort
/dev/loop0 0  0 1  1 /var/lib/snapd/snaps/lxd_24322.snap
 0 512
/dev/loop1 0  0 1  1 /var/lib/snapd/snaps/snapd_18357.snap  
 0 512
/dev/loop2 0  0 1  1 /var/lib/snapd/snaps/core20_1822.snap  
 0 512

# ls -1 /dev/loop*
/dev/loop-control
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
/dev/loop6
/dev/loop7

# truncate -s 1g test1
# truncate -s 1g test2
# ls -lh test1 test2
-rw-r--r-- 1 root root 1.0G Apr  6 17:40 test1
-rw-r--r-- 1 root root 1.0G Apr  6 17:40 test2

# losetup /dev/loop7 test1
# losetup /dev/loop8 test2
losetup: /dev/loop8: failed to set up loop device: No such device or address

...

# losetup --show --find test1
/dev/loop3
# losetup --show --find test1
/dev/loop4
# losetup --show --find test1
/dev/loop5
# losetup --show --find test1
/dev/loop6
# losetup --show --find test1
/dev/loop8
# losetup --show --find test1
/dev/loop9
# losetup --show --find test1
/dev/loop10
# losetup --show --find test1
/dev/loop11
# losetup --show --find test1
/dev/loop12
# losetup --show --find test1
/dev/loop13
# strace -e ioctl losetup --show --find test1
ioctl(3, LOOP_CTL_GET_FREE) = 14
ioctl(4, LOOP_CONFIGURE, {fd=3, block_size=0, info={lo_offset=0, lo_number=0, 
lo_flags=0, lo_file_name="/root/test1", ...}}) = 0
/dev/loop14
+++ exited with 0 +++

# losetup -d /dev/loop3
# losetup -d /dev/loop4
# losetup -d /dev/loop5
# losetup -d /dev/loop6
# losetup -d /dev/loop8
# losetup -d /dev/loop9
# losetup -d /dev/loop10
# losetup -d /dev/loop11
# losetup -d /dev/loop12
# losetup -d /dev/loop13

# losetup /dev/loop8 test2
#

works now.

# cat /sys/module/loop/parameters/max_loop
8

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

Title:
  losetup with mknod fails on jammy with kernel 5.15.0-69-generic

Status in linux package in Ubuntu:
  Confirmed
Status in linux-hwe-5.15 package in Ubuntu:
  New

Bug description:
  losetup fails with devices created manually by mknod on kernel
  5.15.0-69-generic

  # fallocate -l 1G test
  # mknod -m 660 /dev/loop8 b 7 8
  # chown root:disk /dev/loop8
  # losetup /dev/loop8 ./test
  losetup: ./test: failed to set up loop device: Device or resource busy

  Possibly as a result of this patch:
  
https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/

  which was introduced in 5.15.0-68:
  
http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz

  On a machine prior to this change (no issue with losetup):
  # cat /sys/module/loop/parameters/max_loop
  0
  # uname -r
  5.15.0-58-generic

  On a machine after the change (has losetup issue as described above):
  # cat /sys/module/loop/parameters/max_loop
  8
  # uname -r
  5.15.0-69-generic

  So it looks like the default changed and the max amount of loop
  devices that can be created with mknod (not loop-control) is 8. If we
  set max_loop=0 on the kernel command line, it works as before. Cannot
  unload and reload module on a running system to change the parameter
  because it is built into the kernel.

  Another workaround is to use `losetup --find` but that means you
  cannot create with named devices created with mknod.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+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

[Kernel-packages] [Bug 1856871] Re: i/o error if next unused loop device is queried

[Mauricio Faria de Oliveira]

The fix/commit is applied in v5.12, thus available on Jammy
(v5.15-based).

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4ceddce55eb35d15b0f87f5dcf6f0058fd15d3a4


~/git/linux$ git describe --contains 4ceddce55eb35d15b0f87f5dcf6f0058fd15d3a4
v5.12-rc1-dontuse~7^2~13


** Also affects: parted (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: udev (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: snapd (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
   Status: In Progress => Fix Released

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

** Changed in: parted (Ubuntu Jammy)
   Status: New => Invalid

** No longer affects: parted (Ubuntu Jammy)

** No longer affects: snapd (Ubuntu Jammy)

** No longer affects: udev (Ubuntu Jammy)

** No longer affects: systemd (Ubuntu Jammy)

-- 
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/1856871

Title:
  i/o error if next unused loop device is queried

Status in linux package in Ubuntu:
  Fix Released
Status in parted package in Ubuntu:
  Invalid
Status in snapd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in udev package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released

Bug description:
  This is reproducible in Bionic and late.

  Here's an example running 'focal':

  $ lsb_release -cs
  focal

  $ uname -r
  5.3.0-24-generic

  The error is:
  blk_update_request: I/O error, dev loop2, sector 0

  and on more recent kernel:

  kernel: [18135.185709] blk_update_request: I/O error, dev loop18,
  sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0

  
  How to trigger it:
  $ sosreport -o block

  or more precisely the cmd causing the situation inside the block plugin:
  $ parted -s $(losetup -f) unit s print

  https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52

  but if I run it on the next next unused loop device, in this case
  /dev/loop3 (which is also unused), no errors.

  While I agree that sosreport shouldn't query unused loop devices,
  there is definitely something going on with the next unused loop
  device.

  What is differentiate loop2 and loop3 and any other unused ones ?

  3 things so far I have noticed:
  * loop2 is the next unused loop device (losetup -f)
  * A reboot is needed (if some loop modification (snap install, mount loop, 
...) has been made at runtime
  * I have also noticed that loop2 (or whatever the next unused one is) have 
some stat as oppose to other unused loop devices. The stat exist already right 
after the system boot for the next unused loop device.

  /sys/block/loop2/stat
  ::
  2 0 10 0 1 0 0 0 0 0 0

  2  = number of read I/Os processed
  10 = number of sectors read
  1  = number of write I/Os processed

  Explanation of each column:
  https://www.kernel.org/doc/html/latest/block/stat.html

  while /dev/loop3 doesn't

  /sys/block/loop3/stat
  ::
  0 0 0 0 0 0 0 0 0 0 0

  Which tells me that something during the boot process most likely
  acquired (on purpose or not) the next unused loop and possibly didn't
  released it well enough.

  If loop2 is generating errors, and I install a snap, the snap squashfs
  will take loop2, making loop3 the next unused loop device.

  If I query loop3 with 'parted' right after, no errors.

  If I reboot, and query loop3 again, then no I'll have an error.

  To triggers the errors it need to be after a reboot and it only impact
  the first unused loop device available (losetup -f).

  This was tested with focal/systemd whic his very close to latest
  upstream code.

  This has been test with latest v5.5 mainline kernel as well.

  For now, I don't think it's a kernel problem, I'm more thinking of a
  userspace misbehaviour dealing with loop device (or block device) at
  boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+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