Hey Samuel, Ah, the AHCI driver race makes sense! Glad you were able to track that down.
Regarding the patch I sent over a couple of days ago: while trying to reproduce the lockup on QEMU, I actually tripped over a completely separate, perfectly reproducible pager deadlock in the journal itself. The root cause is a classic circular dependency. journal_stop_transaction_locked was performing a memcpy from the live Mach VM cache (bptr) while holding the global j_state_lock. Under heavy memory pressure, if that memcpy triggers a page fault, the VFS thread suspends while holding the lock. The Mach pager is immediately rushed to free RAM, attempts to write a dirty block to disk, tries to acquire the exact same j_state_lock to check for WAL hazards, and the system hard-deadlocks. The patch I sent fixes this by decoupling the memory hydration from the lock. We use a bit of logic to stage the blocks, drop the lock, safely execute the memcpy (so any page faults are harmless), and then re-acquire. It makes the deadlock completely disappear under heavy QEMU load, and as a nice side effect, it noticeably improves throughput on heavy write storms. Take a look when you have a moment and let me know if you have any feedback on the implementation! Kind regards, Milos On Sun, Jun 28, 2026 at 11:31 PM Samuel Thibault <[email protected]> wrote: > Samuel Thibault, le jeu. 25 juin 2026 12:25:34 +0200, a ecrit: > > I'm getting hangs quite often on my i386 hurd box, just by compiling the > > util-linux package on a 50G partition. > > Apparently this only happens when using the in-kernel ahci disk driver, > I'm not getting it with the rumpkernel disk driver. I guess it's the > in-kernel support for cache flush which has some race. > > Samuel >
