[Kernel-packages] [Bug 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
This bug was fixed in the package linux - 4.15.0-161.169
---
linux (4.15.0-161.169) bionic; urgency=medium
* bionic/linux: 4.15.0-161.169 -proposed tracker (LP: #1947358)
* Bionic/linux-aws Boot failure downgrading from Bionic/linux-aws-5.4 on
r5.metal (LP: #1946149)
- SAUCE: Revert "PCI/MSI: Enforce MSI[X] entry updates to be visible"
- SAUCE: Revert "PCI/MSI: Enforce that MSI-X table entry is masked for
update"
linux (4.15.0-160.168) bionic; urgency=medium
* bionic/linux: 4.15.0-160.168 -proposed tracker (LP: #1944933)
* Packaging resync (LP: #1786013)
- debian/dkms-versions -- update from kernel-versions (main/2021.09.27)
* ext4 journal recovery fails w/ data=journal + mmap (LP: #1847340)
- jbd2: introduce/export functions
jbd2_journal_submit|finish_inode_data_buffers()
- jbd2, ext4, ocfs2: introduce/use journal callbacks
j_submit|finish_inode_data_buffers()
- ext4: data=journal: fixes for ext4_page_mkwrite()
- ext4: data=journal: write-protect pages on j_submit_inode_data_buffers()
- ext4: fix mmap write protection for data=journal mode
* CVE-2021-40490
- ext4: fix race writing to an inline_data file while its xattrs are
changing
* Bionic update: upstream stable patchset 2021-09-22 (LP: #1944600)
- iio: humidity: hdc100x: Add margin to the conversion time
- iio: adc: Fix incorrect exit of for-loop
- ASoC: intel: atom: Fix reference to PCM buffer address
- i2c: dev: zero out array used for i2c reads from userspace
- ACPI: NFIT: Fix support for virtual SPA ranges
- ASoC: cs42l42: Correct definition of ADC Volume control
- ASoC: cs42l42: Don't allow SND_SOC_DAIFMT_LEFT_J
- ASoC: cs42l42: Fix inversion of ADC Notch Switch control
- ASoC: cs42l42: Remove duplicate control for WNF filter frequency
- net: dsa: mt7530: add the missing RxUnicast MIB counter
- ppp: Fix generating ifname when empty IFLA_IFNAME is specified
- psample: Add a fwd declaration for skbuff
- net: Fix memory leak in ieee802154_raw_deliver
- net: bridge: fix memleak in br_add_if()
- tcp_bbr: fix u32 wrap bug in round logic if bbr_init() called after 2B
packets
- xen/events: Fix race in set_evtchn_to_irq
- vsock/virtio: avoid potential deadlock when vsock device remove
- powerpc/kprobes: Fix kprobe Oops happens in booke
- x86/tools: Fix objdump version check again
- x86/resctrl: Fix default monitoring groups reporting
- PCI/MSI: Enable and mask MSI-X early
- PCI/MSI: Do not set invalid bits in MSI mask
- PCI/MSI: Correct misleading comments
- PCI/MSI: Use msi_mask_irq() in pci_msi_shutdown()
- PCI/MSI: Protect msi_desc::masked for multi-MSI
- PCI/MSI: Mask all unused MSI-X entries
- PCI/MSI: Enforce that MSI-X table entry is masked for update
- PCI/MSI: Enforce MSI[X] entry updates to be visible
- vmlinux.lds.h: Handle clang's module.{c,d}tor sections
- mac80211: drop data frames without key on encrypted links
- x86/fpu: Make init_fpstate correct with optimized XSAVE
- ath: Use safer key clearing with key cache entries
- ath9k: Clear key cache explicitly on disabling hardware
- ath: Export ath_hw_keysetmac()
- ath: Modify ath_key_delete() to not need full key entry
- ath9k: Postpone key cache entry deletion for TXQ frames reference it
- dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe()
- ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218
- dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller is
not
yet available
- scsi: megaraid_mm: Fix end of loop tests for list_for_each_entry()
- scsi: scsi_dh_rdac: Avoid crash during rdac_bus_attach()
- scsi: core: Avoid printing an error if target_alloc() returns -ENXIO
- ARM: dts: nomadik: Fix up interrupt controller node names
- net: usb: lan78xx: don't modify phy_device state concurrently
- Bluetooth: hidp: use correct wait queue when removing ctrl_wait
- dccp: add do-while-0 stubs for dccp_pr_debug macros
- vhost: Fix the calculation in vhost_overflow()
- bnxt: don't lock the tx queue from napi poll
- net: 6pack: fix slab-out-of-bounds in decode_data
- ptp_pch: Restore dependency on PCI
- net: qlcnic: add missed unlock in qlcnic_83xx_flash_read32
- net: mdio-mux: Don't ignore memory allocation errors
- net: mdio-mux: Handle -EPROBE_DEFER correctly
- mmc: dw_mmc: Fix hang on data CRC error
- ALSA: hda - fix the 'Capture Switch' value change notifications
- ipack: tpci200: fix many double free issues in tpci200_pci_probe
- btrfs: prevent rename2 from exchanging a subvol with a directory from
different parents
- ASoC: intel: atom: Fix breakage for PCM buffer address setup
- locks: print a warning when mount fails due to lack of "mand" support
- fs: warn about impending deprecation of mandatory locks
- netfilter:
[Kernel-packages] [Bug 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
This bug was fixed in the package linux - 5.4.0-89.100 --- linux (5.4.0-89.100) focal; urgency=medium * focal/linux: 5.4.0-89.100 -proposed tracker (LP: #1944901) * Packaging resync (LP: #1786013) - debian/dkms-versions -- update from kernel-versions (main/2021.09.27) * ext4 journal recovery fails w/ data=journal + mmap (LP: #1847340) - jbd2: introduce/export functions jbd2_journal_submit|finish_inode_data_buffers() - jbd2, ext4, ocfs2: introduce/use journal callbacks j_submit|finish_inode_data_buffers() - ext4: data=journal: fixes for ext4_page_mkwrite() - ext4: data=journal: write-protect pages on j_submit_inode_data_buffers() - ext4: fix mmap write protection for data=journal mode * CVE-2021-40490 - ext4: fix race writing to an inline_data file while its xattrs are changing * Obsolete patch "UBUNTU: SAUCE: ext4: fix directory index node split corruption" (LP: #1942902) - Revert "UBUNTU: SAUCE: ext4: fix directory index node split corruption" * psock_snd.sh in net from ubuntu_kernel_selftests ADT failure with focal/groovy/hirsute/impish (LP: #1892213) - selftests/net: remove min gso test in packet_snd * Focal update: v5.4.143 upstream stable release (LP: #1944212) - ext4: fix EXT4_MAX_LOGICAL_BLOCK macro - x86/fpu: Make init_fpstate correct with optimized XSAVE - ath: Use safer key clearing with key cache entries - ath9k: Clear key cache explicitly on disabling hardware - ath: Export ath_hw_keysetmac() - ath: Modify ath_key_delete() to not need full key entry - ath9k: Postpone key cache entry deletion for TXQ frames reference it - mtd: cfi_cmdset_0002: fix crash when erasing/writing AMD cards - media: zr364xx: propagate errors from zr364xx_start_readpipe() - media: zr364xx: fix memory leaks in probe() - media: drivers/media/usb: fix memory leak in zr364xx_probe - USB: core: Avoid WARNings for 0-length descriptor requests - dmaengine: xilinx_dma: Fix read-after-free bug when terminating transfers - dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe() - ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218 - dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller is not yet available - scsi: megaraid_mm: Fix end of loop tests for list_for_each_entry() - scsi: scsi_dh_rdac: Avoid crash during rdac_bus_attach() - scsi: core: Avoid printing an error if target_alloc() returns -ENXIO - scsi: core: Fix capacity set to zero after offlinining device - ARM: dts: nomadik: Fix up interrupt controller node names - net: usb: lan78xx: don't modify phy_device state concurrently - drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X - Bluetooth: hidp: use correct wait queue when removing ctrl_wait - iommu: Check if group is NULL before remove device - cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant - dccp: add do-while-0 stubs for dccp_pr_debug macros - virtio: Protect vqs list access - vhost: Fix the calculation in vhost_overflow() - bpf: Clear zext_dst of dead insns - bnxt: don't lock the tx queue from napi poll - bnxt: disable napi before canceling DIM - net: 6pack: fix slab-out-of-bounds in decode_data - ptp_pch: Restore dependency on PCI - bnxt_en: Add missing DMA memory barriers - vrf: Reset skb conntrack connection on VRF rcv - virtio-net: support XDP when not more queues - virtio-net: use NETIF_F_GRO_HW instead of NETIF_F_LRO - net: qlcnic: add missed unlock in qlcnic_83xx_flash_read32 - net: mdio-mux: Don't ignore memory allocation errors - net: mdio-mux: Handle -EPROBE_DEFER correctly - ovs: clear skb->tstamp in forwarding path - i40e: Fix ATR queue selection - iavf: Fix ping is lost after untrusted VF had tried to change MAC - ovl: add splice file read write helper - mmc: dw_mmc: Fix hang on data CRC error - ALSA: hda - fix the 'Capture Switch' value change notifications - tracing / histogram: Fix NULL pointer dereference on strcmp() on NULL event name - slimbus: messaging: start transaction ids from 1 instead of zero - slimbus: messaging: check for valid transaction id - slimbus: ngd: reset dma setup during runtime pm - ipack: tpci200: fix many double free issues in tpci200_pci_probe - ipack: tpci200: fix memory leak in the tpci200_register - btrfs: prevent rename2 from exchanging a subvol with a directory from different parents - PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI - ASoC: intel: atom: Fix breakage for PCM buffer address setup - mm, memcg: avoid stale protection values when cgroup is above protection - mm: memcontrol: fix occasional OOMs due to proportional memory.low reclaim - fs: warn about impending deprecation of mandatory locks - netfilter: nft_exthdr: fix endianness of tcp option cast -
[Kernel-packages] [Bug 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
Setting tag verification-done-bionic. Test results with stress-ng: 2420 PASSED, 0 FAILED. Test results w/ (x)fstests: no regressions in data=ordered and data=journal (below). --- Bionic, data=ordered: no regression. $ ./fstests-check-logs.sh prop-ordered/xfstests.log* Kernel version: 4.15.0-160-generic #168-Ubuntu - Number of Runs: 10 - Always fail (failed every time) 10 ext4/045 10 generic/044 10 generic/045 10 generic/046 10 generic/082 10 generic/095 10 generic/219 10 generic/230 10 generic/231 10 generic/232 10 generic/233 10 generic/235 10 generic/270 10 generic/299 10 generic/300 10 generic/381 10 generic/382 10 generic/491 10 generic/553 10 generic/554 10 generic/555 10 generic/565 10 generic/566 10 generic/569 10 generic/587 10 generic/598 10 generic/600 10 generic/623 10 generic/629 10 shared/298 - Flaky (failed, but not every time) 2 generic/475 7 generic/388 Bionic, data=journal: no regression. $ ./fstests-check-logs.sh prop-journal/xfstests.log* Kernel version: 4.15.0-160-generic #168-Ubuntu - Number of Runs: 10 - Always fail (failed every time) 10 ext4/045 10 generic/082 10 generic/219 10 generic/223 10 generic/230 10 generic/231 10 generic/232 10 generic/233 10 generic/235 10 generic/270 10 generic/381 10 generic/382 10 generic/441 10 generic/491 10 generic/553 10 generic/554 10 generic/555 10 generic/565 10 generic/566 10 generic/569 10 generic/598 10 generic/600 10 generic/623 10 generic/629 10 shared/298 - Flaky (failed, but not every time) 1 generic/547 5 generic/371 (* improved from Always fail) 7 generic/347 (* improved from Always fail) 7 generic/388 ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1847340 Title: ext4 journal recovery fails w/ data=journal + mmap Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Won't Fix Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Bug description: [Impact] With mmap()ed files on ext4's data journaling it's possible to change a mapped page's buffers contents during their jbd2 transaction commit (as currently nothing prevents/blocks the write access at that time.) This might happen between the buffers checksum calculation and actual write to journal, so the (old) checksum is invalid for the (new) data. If the system crashes after that, but before such journal entry makes it to the filesystem, the journal replay on the next mount just fails, and the filesystem now requires fsck. (apparently curtin might set up /etc/fstab with passno=0, requiring manual intervention.) [39751.096455] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support! [39751.114435] JBD2: Invalid checksum recovering block 87305 in log [39751.146133] JBD2: Invalid checksum recovering block 88039 in log [39751.195950] JBD2: Invalid checksum recovering block 49633 in log [39751.265158] JBD2: recovery failed [39751.265163] EXT4-fs (vdc): error loading journal [Fix] The fix is to write-protect the pages during journal transaction commit, so that writes to mapped pages hit a page fault, then ext4's page_mkwrite hook can block until the commit finishes and the buffers can be modified. In order to do that, add jbd2 journal callbacks that the filesystems can customize, called before/after the critical region in transaction commit, then have ext4 in data journaling mode to write-protect the pages whose buffers are being committed (and handle cases that need pages redirtied.) The changes are restricted to the data journaling mode and page_mkwrite hook, and other modes/paths use the same code/behavior in the callbacks. [Test Case] Set up an ext4 filesystem in data journaling mode, and run stress-ng's mmap file test on it, then crash the system after a bit; check whether the filesystem can mount again or not (i.e., with jbd2 checksum errors.) # mkfs.ext4 $DEV # mount -o data=journal $DEV $DIR # cd $DIR # stress-ng --mmap $((4*$(nproc))) --mmap-file & # sleep 60 # echo c >/proc/sysrq-trigger ... # mount -o data=journal $DEV $DIR # PASS/FAIL. # dmesg | tail [Regression Potential] Regressions would likely manifest in ext4 data journaling mode (which is not the default mode,
[Kernel-packages] [Bug 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
Setting tag verification-done-focal. Test results with stress-ng: 700 PASSED, 0 FAILED. Test results w/ (x)fstests: no regressions in data=ordered and data=journal (below). --- Focal, data=ordered: no regression. $ ./fstests-check-logs.sh prop-ordered/xfstests.log* Kernel version: 5.4.0-89-generic #100-Ubuntu - Number of Runs: 10 - Always fail (failed every time) 10 ext4/024 10 ext4/034 10 ext4/045 10 generic/044 10 generic/045 10 generic/046 10 generic/082 10 generic/219 10 generic/230 10 generic/231 10 generic/232 10 generic/233 10 generic/235 10 generic/270 10 generic/381 10 generic/382 10 generic/397 10 generic/398 10 generic/399 10 generic/419 10 generic/421 10 generic/429 10 generic/435 10 generic/440 10 generic/484 10 generic/548 10 generic/549 10 generic/550 10 generic/566 10 generic/587 10 generic/600 - Flaky (failed, but not every time) 3 generic/388 Focal, data=journal: no regression. $ ./fstests-check-logs.sh prop-journal/xfstests.log* Kernel version: 5.4.0-89-generic #100-Ubuntu - Number of Runs: 10 - Always fail (failed every time) 10 ext4/024 10 ext4/034 10 ext4/045 10 generic/082 10 generic/219 10 generic/223 10 generic/230 10 generic/231 10 generic/232 10 generic/233 10 generic/235 10 generic/270 10 generic/381 10 generic/382 10 generic/397 10 generic/398 10 generic/399 10 generic/419 10 generic/421 10 generic/429 10 generic/435 10 generic/440 10 generic/441 10 generic/537 10 generic/548 10 generic/549 10 generic/550 10 generic/566 10 generic/600 - Flaky (failed, but not every time) 1 generic/127 1 generic/528 4 generic/388 9 generic/347 ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1847340 Title: ext4 journal recovery fails w/ data=journal + mmap Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Won't Fix Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Bug description: [Impact] With mmap()ed files on ext4's data journaling it's possible to change a mapped page's buffers contents during their jbd2 transaction commit (as currently nothing prevents/blocks the write access at that time.) This might happen between the buffers checksum calculation and actual write to journal, so the (old) checksum is invalid for the (new) data. If the system crashes after that, but before such journal entry makes it to the filesystem, the journal replay on the next mount just fails, and the filesystem now requires fsck. (apparently curtin might set up /etc/fstab with passno=0, requiring manual intervention.) [39751.096455] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support! [39751.114435] JBD2: Invalid checksum recovering block 87305 in log [39751.146133] JBD2: Invalid checksum recovering block 88039 in log [39751.195950] JBD2: Invalid checksum recovering block 49633 in log [39751.265158] JBD2: recovery failed [39751.265163] EXT4-fs (vdc): error loading journal [Fix] The fix is to write-protect the pages during journal transaction commit, so that writes to mapped pages hit a page fault, then ext4's page_mkwrite hook can block until the commit finishes and the buffers can be modified. In order to do that, add jbd2 journal callbacks that the filesystems can customize, called before/after the critical region in transaction commit, then have ext4 in data journaling mode to write-protect the pages whose buffers are being committed (and handle cases that need pages redirtied.) The changes are restricted to the data journaling mode and page_mkwrite hook, and other modes/paths use the same code/behavior in the callbacks. [Test Case] Set up an ext4 filesystem in data journaling mode, and run stress-ng's mmap file test on it, then crash the system after a bit; check whether the filesystem can mount again or not (i.e., with jbd2 checksum errors.) # mkfs.ext4 $DEV # mount -o data=journal $DEV $DIR # cd $DIR # stress-ng --mmap $((4*$(nproc))) --mmap-file & # sleep 60 # echo c >/proc/sysrq-trigger ... # mount -o data=journal $DEV $DIR # PASS/FAIL. # dmesg | tail [Regression Potential] Regressions would likely manifest in ext4 data journaling mode (which is not the
[Kernel-packages] [Bug 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
This bug is awaiting verification that the linux/4.15.0-160.168 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-bionic -- 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/1847340 Title: ext4 journal recovery fails w/ data=journal + mmap Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Won't Fix Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Bug description: [Impact] With mmap()ed files on ext4's data journaling it's possible to change a mapped page's buffers contents during their jbd2 transaction commit (as currently nothing prevents/blocks the write access at that time.) This might happen between the buffers checksum calculation and actual write to journal, so the (old) checksum is invalid for the (new) data. If the system crashes after that, but before such journal entry makes it to the filesystem, the journal replay on the next mount just fails, and the filesystem now requires fsck. (apparently curtin might set up /etc/fstab with passno=0, requiring manual intervention.) [39751.096455] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support! [39751.114435] JBD2: Invalid checksum recovering block 87305 in log [39751.146133] JBD2: Invalid checksum recovering block 88039 in log [39751.195950] JBD2: Invalid checksum recovering block 49633 in log [39751.265158] JBD2: recovery failed [39751.265163] EXT4-fs (vdc): error loading journal [Fix] The fix is to write-protect the pages during journal transaction commit, so that writes to mapped pages hit a page fault, then ext4's page_mkwrite hook can block until the commit finishes and the buffers can be modified. In order to do that, add jbd2 journal callbacks that the filesystems can customize, called before/after the critical region in transaction commit, then have ext4 in data journaling mode to write-protect the pages whose buffers are being committed (and handle cases that need pages redirtied.) The changes are restricted to the data journaling mode and page_mkwrite hook, and other modes/paths use the same code/behavior in the callbacks. [Test Case] Set up an ext4 filesystem in data journaling mode, and run stress-ng's mmap file test on it, then crash the system after a bit; check whether the filesystem can mount again or not (i.e., with jbd2 checksum errors.) # mkfs.ext4 $DEV # mount -o data=journal $DEV $DIR # cd $DIR # stress-ng --mmap $((4*$(nproc))) --mmap-file & # sleep 60 # echo c >/proc/sysrq-trigger ... # mount -o data=journal $DEV $DIR # PASS/FAIL. # dmesg | tail [Regression Potential] Regressions would likely manifest in ext4 data journaling mode (which is not the default mode, 'ordered') with memory mapped access, as the other modes/paths are largely unaffected by the changes/same behavior. This has been tested with (x)fstests, that showed no regressions on data=ordered and data=journal on both Bionic and Focal (with kernel versions 4.15.0-156-generic and 5.4.0-84-generic) w/in 10 runs each. And the stress-ng test-case as well. (Numbers/details in the LP bug.) [Other info] The patchset is applied on 5.10, so Hirsute (5.11) is already fixed; only Focal and Bionic need it. There are little changes in the patches between Focal and Bionic (mostly minor backport adjustments, mainly due to no vm_fault_t) but unfortunately that needs separate versions for most patches. ... [Original Bug Description] [Impact] In the event of a loss of power, ext4 filesystems mounted w/ data=journal,journal_checksum are subject to a corruption issue that requires a fsck to recover. This is exacerbated by installations by curtin that set passno=0 in /etc/fstab, preventing fsck from running automatically and thus requiring a manual recovery. And *that* is further exacerbated because initramfs-tools is smart enough to not include fsck.ext4 when passno=0 is detected in /etc/fstab, requiring the user to boot from recovery media. [Test Case] Forcibly power cycle a system
[Kernel-packages] [Bug 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
This bug is awaiting verification that the linux/5.4.0-89.100 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-focal -- 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/1847340 Title: ext4 journal recovery fails w/ data=journal + mmap Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Won't Fix Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Bug description: [Impact] With mmap()ed files on ext4's data journaling it's possible to change a mapped page's buffers contents during their jbd2 transaction commit (as currently nothing prevents/blocks the write access at that time.) This might happen between the buffers checksum calculation and actual write to journal, so the (old) checksum is invalid for the (new) data. If the system crashes after that, but before such journal entry makes it to the filesystem, the journal replay on the next mount just fails, and the filesystem now requires fsck. (apparently curtin might set up /etc/fstab with passno=0, requiring manual intervention.) [39751.096455] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support! [39751.114435] JBD2: Invalid checksum recovering block 87305 in log [39751.146133] JBD2: Invalid checksum recovering block 88039 in log [39751.195950] JBD2: Invalid checksum recovering block 49633 in log [39751.265158] JBD2: recovery failed [39751.265163] EXT4-fs (vdc): error loading journal [Fix] The fix is to write-protect the pages during journal transaction commit, so that writes to mapped pages hit a page fault, then ext4's page_mkwrite hook can block until the commit finishes and the buffers can be modified. In order to do that, add jbd2 journal callbacks that the filesystems can customize, called before/after the critical region in transaction commit, then have ext4 in data journaling mode to write-protect the pages whose buffers are being committed (and handle cases that need pages redirtied.) The changes are restricted to the data journaling mode and page_mkwrite hook, and other modes/paths use the same code/behavior in the callbacks. [Test Case] Set up an ext4 filesystem in data journaling mode, and run stress-ng's mmap file test on it, then crash the system after a bit; check whether the filesystem can mount again or not (i.e., with jbd2 checksum errors.) # mkfs.ext4 $DEV # mount -o data=journal $DEV $DIR # cd $DIR # stress-ng --mmap $((4*$(nproc))) --mmap-file & # sleep 60 # echo c >/proc/sysrq-trigger ... # mount -o data=journal $DEV $DIR # PASS/FAIL. # dmesg | tail [Regression Potential] Regressions would likely manifest in ext4 data journaling mode (which is not the default mode, 'ordered') with memory mapped access, as the other modes/paths are largely unaffected by the changes/same behavior. This has been tested with (x)fstests, that showed no regressions on data=ordered and data=journal on both Bionic and Focal (with kernel versions 4.15.0-156-generic and 5.4.0-84-generic) w/in 10 runs each. And the stress-ng test-case as well. (Numbers/details in the LP bug.) [Other info] The patchset is applied on 5.10, so Hirsute (5.11) is already fixed; only Focal and Bionic need it. There are little changes in the patches between Focal and Bionic (mostly minor backport adjustments, mainly due to no vm_fault_t) but unfortunately that needs separate versions for most patches. ... [Original Bug Description] [Impact] In the event of a loss of power, ext4 filesystems mounted w/ data=journal,journal_checksum are subject to a corruption issue that requires a fsck to recover. This is exacerbated by installations by curtin that set passno=0 in /etc/fstab, preventing fsck from running automatically and thus requiring a manual recovery. And *that* is further exacerbated because initramfs-tools is smart enough to not include fsck.ext4 when passno=0 is detected in /etc/fstab, requiring the user to boot from recovery media. [Test Case] Forcibly power cycle a system running
[Kernel-packages] [Bug 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
** Changed in: linux (Ubuntu Focal) Status: In Progress => Fix Committed -- 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/1847340 Title: ext4 journal recovery fails w/ data=journal + mmap Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Won't Fix Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Bug description: [Impact] With mmap()ed files on ext4's data journaling it's possible to change a mapped page's buffers contents during their jbd2 transaction commit (as currently nothing prevents/blocks the write access at that time.) This might happen between the buffers checksum calculation and actual write to journal, so the (old) checksum is invalid for the (new) data. If the system crashes after that, but before such journal entry makes it to the filesystem, the journal replay on the next mount just fails, and the filesystem now requires fsck. (apparently curtin might set up /etc/fstab with passno=0, requiring manual intervention.) [39751.096455] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support! [39751.114435] JBD2: Invalid checksum recovering block 87305 in log [39751.146133] JBD2: Invalid checksum recovering block 88039 in log [39751.195950] JBD2: Invalid checksum recovering block 49633 in log [39751.265158] JBD2: recovery failed [39751.265163] EXT4-fs (vdc): error loading journal [Fix] The fix is to write-protect the pages during journal transaction commit, so that writes to mapped pages hit a page fault, then ext4's page_mkwrite hook can block until the commit finishes and the buffers can be modified. In order to do that, add jbd2 journal callbacks that the filesystems can customize, called before/after the critical region in transaction commit, then have ext4 in data journaling mode to write-protect the pages whose buffers are being committed (and handle cases that need pages redirtied.) The changes are restricted to the data journaling mode and page_mkwrite hook, and other modes/paths use the same code/behavior in the callbacks. [Test Case] Set up an ext4 filesystem in data journaling mode, and run stress-ng's mmap file test on it, then crash the system after a bit; check whether the filesystem can mount again or not (i.e., with jbd2 checksum errors.) # mkfs.ext4 $DEV # mount -o data=journal $DEV $DIR # cd $DIR # stress-ng --mmap $((4*$(nproc))) --mmap-file & # sleep 60 # echo c >/proc/sysrq-trigger ... # mount -o data=journal $DEV $DIR # PASS/FAIL. # dmesg | tail [Regression Potential] Regressions would likely manifest in ext4 data journaling mode (which is not the default mode, 'ordered') with memory mapped access, as the other modes/paths are largely unaffected by the changes/same behavior. This has been tested with (x)fstests, that showed no regressions on data=ordered and data=journal on both Bionic and Focal (with kernel versions 4.15.0-156-generic and 5.4.0-84-generic) w/in 10 runs each. And the stress-ng test-case as well. (Numbers/details in the LP bug.) [Other info] The patchset is applied on 5.10, so Hirsute (5.11) is already fixed; only Focal and Bionic need it. There are little changes in the patches between Focal and Bionic (mostly minor backport adjustments, mainly due to no vm_fault_t) but unfortunately that needs separate versions for most patches. ... [Original Bug Description] [Impact] In the event of a loss of power, ext4 filesystems mounted w/ data=journal,journal_checksum are subject to a corruption issue that requires a fsck to recover. This is exacerbated by installations by curtin that set passno=0 in /etc/fstab, preventing fsck from running automatically and thus requiring a manual recovery. And *that* is further exacerbated because initramfs-tools is smart enough to not include fsck.ext4 when passno=0 is detected in /etc/fstab, requiring the user to boot from recovery media. [Test Case] Forcibly power cycle a system running 'stress-ng --dir 0'. I've created a package to automate the reproduction: https://git.launchpad.net/~dannf/+git/dgx2-ext4-csum-repro?h=master [Fix] [Regression Risk] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847340/+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 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
** Changed in: linux (Ubuntu Bionic) Status: In Progress => Fix Committed -- 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/1847340 Title: ext4 journal recovery fails w/ data=journal + mmap Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Won't Fix Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: In Progress Status in linux source package in Hirsute: Fix Released Bug description: [Impact] With mmap()ed files on ext4's data journaling it's possible to change a mapped page's buffers contents during their jbd2 transaction commit (as currently nothing prevents/blocks the write access at that time.) This might happen between the buffers checksum calculation and actual write to journal, so the (old) checksum is invalid for the (new) data. If the system crashes after that, but before such journal entry makes it to the filesystem, the journal replay on the next mount just fails, and the filesystem now requires fsck. (apparently curtin might set up /etc/fstab with passno=0, requiring manual intervention.) [39751.096455] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support! [39751.114435] JBD2: Invalid checksum recovering block 87305 in log [39751.146133] JBD2: Invalid checksum recovering block 88039 in log [39751.195950] JBD2: Invalid checksum recovering block 49633 in log [39751.265158] JBD2: recovery failed [39751.265163] EXT4-fs (vdc): error loading journal [Fix] The fix is to write-protect the pages during journal transaction commit, so that writes to mapped pages hit a page fault, then ext4's page_mkwrite hook can block until the commit finishes and the buffers can be modified. In order to do that, add jbd2 journal callbacks that the filesystems can customize, called before/after the critical region in transaction commit, then have ext4 in data journaling mode to write-protect the pages whose buffers are being committed (and handle cases that need pages redirtied.) The changes are restricted to the data journaling mode and page_mkwrite hook, and other modes/paths use the same code/behavior in the callbacks. [Test Case] Set up an ext4 filesystem in data journaling mode, and run stress-ng's mmap file test on it, then crash the system after a bit; check whether the filesystem can mount again or not (i.e., with jbd2 checksum errors.) # mkfs.ext4 $DEV # mount -o data=journal $DEV $DIR # cd $DIR # stress-ng --mmap $((4*$(nproc))) --mmap-file & # sleep 60 # echo c >/proc/sysrq-trigger ... # mount -o data=journal $DEV $DIR # PASS/FAIL. # dmesg | tail [Regression Potential] Regressions would likely manifest in ext4 data journaling mode (which is not the default mode, 'ordered') with memory mapped access, as the other modes/paths are largely unaffected by the changes/same behavior. This has been tested with (x)fstests, that showed no regressions on data=ordered and data=journal on both Bionic and Focal (with kernel versions 4.15.0-156-generic and 5.4.0-84-generic) w/in 10 runs each. And the stress-ng test-case as well. (Numbers/details in the LP bug.) [Other info] The patchset is applied on 5.10, so Hirsute (5.11) is already fixed; only Focal and Bionic need it. There are little changes in the patches between Focal and Bionic (mostly minor backport adjustments, mainly due to no vm_fault_t) but unfortunately that needs separate versions for most patches. ... [Original Bug Description] [Impact] In the event of a loss of power, ext4 filesystems mounted w/ data=journal,journal_checksum are subject to a corruption issue that requires a fsck to recover. This is exacerbated by installations by curtin that set passno=0 in /etc/fstab, preventing fsck from running automatically and thus requiring a manual recovery. And *that* is further exacerbated because initramfs-tools is smart enough to not include fsck.ext4 when passno=0 is detected in /etc/fstab, requiring the user to boot from recovery media. [Test Case] Forcibly power cycle a system running 'stress-ng --dir 0'. I've created a package to automate the reproduction: https://git.launchpad.net/~dannf/+git/dgx2-ext4-csum-repro?h=master [Fix] [Regression Risk] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847340/+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 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
Just updating the numbers for Focal / Original in comment #9 (the issue did happen more times overnight.) [ 10.018315] rc.local[744]: 61 FAILED [ 10.018882] rc.local[744]:1186 PASSED -- 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/1847340 Title: ext4 journal recovery fails w/ data=journal + mmap Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: In Progress Status in linux source package in Disco: Won't Fix Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: In Progress Status in linux source package in Hirsute: Fix Released Bug description: [Impact] With mmap()ed files on ext4's data journaling it's possible to change a mapped page's buffers contents during their jbd2 transaction commit (as currently nothing prevents/blocks the write access at that time.) This might happen between the buffers checksum calculation and actual write to journal, so the (old) checksum is invalid for the (new) data. If the system crashes after that, but before such journal entry makes it to the filesystem, the journal replay on the next mount just fails, and the filesystem now requires fsck. (apparently curtin might set up /etc/fstab with passno=0, requiring manual intervention.) [39751.096455] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support! [39751.114435] JBD2: Invalid checksum recovering block 87305 in log [39751.146133] JBD2: Invalid checksum recovering block 88039 in log [39751.195950] JBD2: Invalid checksum recovering block 49633 in log [39751.265158] JBD2: recovery failed [39751.265163] EXT4-fs (vdc): error loading journal [Fix] The fix is to write-protect the pages during journal transaction commit, so that writes to mapped pages hit a page fault, then ext4's page_mkwrite hook can block until the commit finishes and the buffers can be modified. In order to do that, add jbd2 journal callbacks that the filesystems can customize, called before/after the critical region in transaction commit, then have ext4 in data journaling mode to write-protect the pages whose buffers are being committed (and handle cases that need pages redirtied.) The changes are restricted to the data journaling mode and page_mkwrite hook, and other modes/paths use the same code/behavior in the callbacks. [Test Case] Set up an ext4 filesystem in data journaling mode, and run stress-ng's mmap file test on it, then crash the system after a bit; check whether the filesystem can mount again or not (i.e., with jbd2 checksum errors.) # mkfs.ext4 $DEV # mount -o data=journal $DEV $DIR # cd $DIR # stress-ng --mmap $((4*$(nproc))) --mmap-file & # sleep 60 # echo c >/proc/sysrq-trigger ... # mount -o data=journal $DEV $DIR # PASS/FAIL. # dmesg | tail [Regression Potential] Regressions would likely manifest in ext4 data journaling mode (which is not the default mode, 'ordered') with memory mapped access, as the other modes/paths are largely unaffected by the changes/same behavior. This has been tested with (x)fstests, that showed no regressions on data=ordered and data=journal on both Bionic and Focal (with kernel versions 4.15.0-156-generic and 5.4.0-84-generic) w/in 10 runs each. And the stress-ng test-case as well. (Numbers/details in the LP bug.) [Other info] The patchset is applied on 5.10, so Hirsute (5.11) is already fixed; only Focal and Bionic need it. There are little changes in the patches between Focal and Bionic (mostly minor backport adjustments, mainly due to no vm_fault_t) but unfortunately that needs separate versions for most patches. ... [Original Bug Description] [Impact] In the event of a loss of power, ext4 filesystems mounted w/ data=journal,journal_checksum are subject to a corruption issue that requires a fsck to recover. This is exacerbated by installations by curtin that set passno=0 in /etc/fstab, preventing fsck from running automatically and thus requiring a manual recovery. And *that* is further exacerbated because initramfs-tools is smart enough to not include fsck.ext4 when passno=0 is detected in /etc/fstab, requiring the user to boot from recovery media. [Test Case] Forcibly power cycle a system running 'stress-ng --dir 0'. I've created a package to automate the reproduction: https://git.launchpad.net/~dannf/+git/dgx2-ext4-csum-repro?h=master [Fix] [Regression Risk] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847340/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help
[Kernel-packages] [Bug 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
Patches posted for SRU. [B/F][PATCH 0/5] ext4/jbd2: data=journal: write-protect pages on transaction commit https://lists.ubuntu.com/archives/kernel-team/2021-September/123963.html -- 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/1847340 Title: ext4 journal recovery fails w/ data=journal + mmap Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: In Progress Status in linux source package in Disco: Won't Fix Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: In Progress Status in linux source package in Hirsute: Fix Released Bug description: [Impact] With mmap()ed files on ext4's data journaling it's possible to change a mapped page's buffers contents during their jbd2 transaction commit (as currently nothing prevents/blocks the write access at that time.) This might happen between the buffers checksum calculation and actual write to journal, so the (old) checksum is invalid for the (new) data. If the system crashes after that, but before such journal entry makes it to the filesystem, the journal replay on the next mount just fails, and the filesystem now requires fsck. (apparently curtin might set up /etc/fstab with passno=0, requiring manual intervention.) [39751.096455] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support! [39751.114435] JBD2: Invalid checksum recovering block 87305 in log [39751.146133] JBD2: Invalid checksum recovering block 88039 in log [39751.195950] JBD2: Invalid checksum recovering block 49633 in log [39751.265158] JBD2: recovery failed [39751.265163] EXT4-fs (vdc): error loading journal [Fix] The fix is to write-protect the pages during journal transaction commit, so that writes to mapped pages hit a page fault, then ext4's page_mkwrite hook can block until the commit finishes and the buffers can be modified. In order to do that, add jbd2 journal callbacks that the filesystems can customize, called before/after the critical region in transaction commit, then have ext4 in data journaling mode to write-protect the pages whose buffers are being committed (and handle cases that need pages redirtied.) The changes are restricted to the data journaling mode and page_mkwrite hook, and other modes/paths use the same code/behavior in the callbacks. [Test Case] Set up an ext4 filesystem in data journaling mode, and run stress-ng's mmap file test on it, then crash the system after a bit; check whether the filesystem can mount again or not (i.e., with jbd2 checksum errors.) # mkfs.ext4 $DEV # mount -o data=journal $DEV $DIR # cd $DIR # stress-ng --mmap $((4*$(nproc))) --mmap-file & # sleep 60 # echo c >/proc/sysrq-trigger ... # mount -o data=journal $DEV $DIR # PASS/FAIL. # dmesg | tail [Regression Potential] Regressions would likely manifest in ext4 data journaling mode (which is not the default mode, 'ordered') with memory mapped access, as the other modes/paths are largely unaffected by the changes/same behavior. This has been tested with (x)fstests, that showed no regressions on data=ordered and data=journal on both Bionic and Focal (with kernel versions 4.15.0-156-generic and 5.4.0-84-generic) w/in 10 runs each. And the stress-ng test-case as well. (Numbers/details in the LP bug.) [Other info] The patchset is applied on 5.10, so Hirsute (5.11) is already fixed; only Focal and Bionic need it. There are little changes in the patches between Focal and Bionic (mostly minor backport adjustments, mainly due to no vm_fault_t) but unfortunately that needs separate versions for most patches. ... [Original Bug Description] [Impact] In the event of a loss of power, ext4 filesystems mounted w/ data=journal,journal_checksum are subject to a corruption issue that requires a fsck to recover. This is exacerbated by installations by curtin that set passno=0 in /etc/fstab, preventing fsck from running automatically and thus requiring a manual recovery. And *that* is further exacerbated because initramfs-tools is smart enough to not include fsck.ext4 when passno=0 is detected in /etc/fstab, requiring the user to boot from recovery media. [Test Case] Forcibly power cycle a system running 'stress-ng --dir 0'. I've created a package to automate the reproduction: https://git.launchpad.net/~dannf/+git/dgx2-ext4-csum-repro?h=master [Fix] [Regression Risk] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847340/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help :
[Kernel-packages] [Bug 1847340] Re: ext4 journal recovery fails w/ data=journal + mmap
** Summary changed: - ext4 journal recovery fails w/ data=journal + journal_checksum + mmap + ext4 journal recovery fails w/ data=journal + mmap -- 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/1847340 Title: ext4 journal recovery fails w/ data=journal + mmap Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: In Progress Status in linux source package in Disco: Won't Fix Status in linux source package in Eoan: Won't Fix Status in linux source package in Focal: In Progress Status in linux source package in Hirsute: Fix Released Bug description: [Impact] With mmap()ed files on ext4's data journaling it's possible to change a mapped page's buffers contents during their jbd2 transaction commit (as currently nothing prevents/blocks the write access at that time.) This might happen between the buffers checksum calculation and actual write to journal, so the (old) checksum is invalid for the (new) data. If the system crashes after that, but before such journal entry makes it to the filesystem, the journal replay on the next mount just fails, and the filesystem now requires fsck. (apparently curtin might set up /etc/fstab with passno=0, requiring manual intervention.) [39751.096455] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support! [39751.114435] JBD2: Invalid checksum recovering block 87305 in log [39751.146133] JBD2: Invalid checksum recovering block 88039 in log [39751.195950] JBD2: Invalid checksum recovering block 49633 in log [39751.265158] JBD2: recovery failed [39751.265163] EXT4-fs (vdc): error loading journal [Fix] The fix is to write-protect the pages during journal transaction commit, so that writes to mapped pages hit a page fault, then ext4's page_mkwrite hook can block until the commit finishes and the buffers can be modified. In order to do that, add jbd2 journal callbacks that the filesystems can customize, called before/after the critical region in transaction commit, then have ext4 in data journaling mode to write-protect the pages whose buffers are being committed (and handle cases that need pages redirtied.) The changes are restricted to the data journaling mode and page_mkwrite hook, and other modes/paths use the same code/behavior in the callbacks. [Test Case] Set up an ext4 filesystem in data journaling mode, and run stress-ng's mmap file test on it, then crash the system after a bit; check whether the filesystem can mount again or not (i.e., with jbd2 checksum errors.) # mkfs.ext4 $DEV # mount -o data=journal $DEV $DIR # cd $DIR # stress-ng --mmap $((4*$(nproc))) --mmap-file & # sleep 60 # echo c >/proc/sysrq-trigger ... # mount -o data=journal $DEV $DIR # PASS/FAIL. # dmesg | tail [Regression Potential] Regressions would likely manifest in ext4 data journaling mode (which is not the default mode, 'ordered') with memory mapped access, as the other modes/paths are largely unaffected by the changes/same behavior. This has been tested with (x)fstests, that showed no regressions on data=ordered and data=journal on both Bionic and Focal (with kernel versions 4.15.0-156-generic and 5.4.0-84-generic) w/in 10 runs each. And the stress-ng test-case as well. (Numbers/details in the LP bug.) [Other info] The patchset is applied on 5.10, so Hirsute (5.11) is already fixed; only Focal and Bionic need it. There are little changes in the patches between Focal and Bionic (mostly minor backport adjustments, mainly due to no vm_fault_t) but unfortunately that needs separate versions for most patches. ... [Original Bug Description] [Impact] In the event of a loss of power, ext4 filesystems mounted w/ data=journal,journal_checksum are subject to a corruption issue that requires a fsck to recover. This is exacerbated by installations by curtin that set passno=0 in /etc/fstab, preventing fsck from running automatically and thus requiring a manual recovery. And *that* is further exacerbated because initramfs-tools is smart enough to not include fsck.ext4 when passno=0 is detected in /etc/fstab, requiring the user to boot from recovery media. [Test Case] Forcibly power cycle a system running 'stress-ng --dir 0'. I've created a package to automate the reproduction: https://git.launchpad.net/~dannf/+git/dgx2-ext4-csum-repro?h=master [Fix] [Regression Risk] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847340/+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
