[Bug 2172527] Re: linux 7.0.0-42: writeback deadlock — sync() never returns with >1 GB dirty pages and an idle disk (full system freeze)

Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2172527 Title: linux 7.0.0-42: writeback deadlock — sync() never returns with >1 GB dirty pages and an idle disk (full system freeze) Status in linux package in Ubuntu: Confirmed Bug description: **Package:** `linux` (source) — affects `linux-image-7.0.0-42-generic 7.0.0-42.42` --- ## Problem description After upgrading from `linux-image-7.0.0-38-generic` to `linux-image-7.0.0-42-generic` (installed 2026-10-29 12:46 EEST via unattended-upgrades), the machine started freezing completely, several times per session, requiring a hard power-off. The freeze is a **writeback deadlock at the kernel level**, not a slow or failing disk: the block device is completely idle (`inflight = 0`, ~0.3 MiB/s written) while more than 1 GB of dirty pages never reach it. ## Regression range | Boot | Kernel | Time (EEST) | Result | |------|--------|-------------|--------| | 12:33–12:58 | 7.0.0-38 | before upgrade | clean, normal shutdown | | 13:00–17:05 | 7.0.0-42 | after upgrade | `EXT4-fs error` on sdb2, writeback stalls, systemd-oomd kill | | 17:20–18:53 | 7.0.0-42 | | journal ends abruptly mid-line → hard freeze | | 18:55–20:02 | 7.0.0-42 | | 52 × "waiting for writeback completion", up to 386 s | | 20:17–now | 7.0.0-38 | after rollback | clean, `sync` returns in 0.068 s | Bisected by kernel rollback only; no other component was changed when testing -38. ## Steps to reproduce 1. Boot `7.0.0-42-generic` on this machine with Docker running (7 containers). 2. Generate moderate write load (container churn, browser start, Go builds). 3. Within minutes the system stops responding; any process that writes enters D state. ## Actual behaviour - `sync` never returns: ``` PID 114212 D wb_wait_for_completion sync (killed by Ctrl-C after >120 s, remained stuck) ``` - Dirty pages never flushed, device idle: ``` Dirty: 1387248 kB Writeback: 2244 kB ``` `/sys/block/sda/stat` sampled over 5 s: ``` read 0.00 MiB/s write 0.29 MiB/s inflight = 0 ``` - Kernel hung-task detector: ``` INFO: The task dockerd:14019 has been waiting for writeback completion for more than 386 seconds. INFO: task dockerd:3461 <writer> blocked on an rw-semaphore likely owned by task dockerd:14015 <writer> INFO: task kworker/1:0:23825 blocked for more than 368 seconds. ``` - `flush-8:0` and `inode_switch_wbs` kworkers in D state. - `/proc/pressure/io`: `some avg10 = 84.37`, `full avg10 = 72.81` while the disk is idle. - All writers enter D state: `brave` in `submit_bio_wait` / `folio_wait_bit_common`, GNOME Shell stops repainting, `journald` reports `system.journal corrupted or uncleanly shut down` after each forced reboot. - `systemd-oomd` fired once because of the dirty-page pressure (`Pressure: Avg10: 87.24` → killed the kitty scope). ## Expected behaviour `sync` completes, `Dirty` returns to ~0, and the system stays responsive. ## Evidence that the storage device is NOT the cause - No `ata3.00: exception`, `failed command`, `Sense Key`, `Medium Error`, `critical medium error` or `Buffer I/O error` in any affected boot. - SMART: `Current_Pending_Sector = 8` and `Offline_Uncorrectable = 0`, both unchanged for over a year (pre-existing, no new reallocations, `UDMA_CRC_Error_Count = 0`, temperature 40 °C). - Reads and metadata operations continue working while writes are stuck — the device answers, it simply is never asked to write. - On the same disk and same filesystem, `7.0.0-38` handles the same workload with `sync` in 0.068 s and `Dirty: 0 kB`. ## Suspected area `wb_wait_for_completion()` / cgroup writeback (`inode_switch_wbs`) does not make progress. Possibly related to the cgroup-writeback changes tracked in LP #2170496 (panic in `rcu_do_batch`, suspected `cgroup_writeback_umount`), and to the Docker workload in LP #2172422. The writeback workqueue appears to stop being scheduled: the device queue is empty and `Writeback` stays ≈2 MB while `Dirty` grows to 1.3 GB. ## Workaround Pin the kernel to `7.0.0-38.38`; the regression disappears immediately. ## Attachments - `kernel-7.0.0-42-boot-1300-1705.txt` — first -42 boot (10 writeback stalls, 3 EXT4 errors) - `kernel-7.0.0-42-boot-1720-1853.txt` — second -42 boot, journal ends abruptly (hard freeze) - `kernel-7.0.0-42-boot-1855-2002.txt` — third -42 boot (52 writeback stalls, up to 386 s) - `live-snapshot.txt` — uname, meminfo, PSI, diskstats, kernel versions, apt holds - `linux-bug.apport` — `apport-cli -f -p linux` collection ## System information ``` Ubuntu 26.04.1 LTS (Resolute Raccoon) Lenovo ThinkPad T480 (20L5) Intel Core i7-8550U, Intel UHD Graphics 620 (i915) GNOME 50.1 / Wayland, Mesa 26.0.8, systemd 259.5 ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172527/+subscriptions