### System details

AMD Ryzen 7 9800X3D, AMD Radeon RX 7900 XTX, 32 GB non-ECC, ASUS ROG STRIX X870-A GAMING WIFI (BIOS 1605, 2025-07-15), Samsung 990 EVO Plus 2TB (firmware 2B2QKXG7). Omarchy kernel `linux-omarchy 7.2.5-3` (`7.2.5-3-omarchy`, PREEMPT(full), commit `240f9ec5a8022b1a7f578b0199033bf067658fbc`). LUKS2 + btrfs, subvolumes `@` and `@home`, cmdline `rootflags=subvol=@`, `zswap.enabled=0`, resume on a ~31 GiB btrfs swapfile on the same filesystem. Filesystem about 43% full (~788 GiB used of 1.82 TiB).

### What's wrong?

One boot of `7.2.5-3-omarchy` ran from 2026-10-01 21:06 UTC to 2026-10-05 11:58 UTC. The filesystem was forced read-only at the end. The damaged metadata was not committed. This does not look like a failing NVMe, and it does not look like an Omarchy userspace config fault. It happened inside the patched kernel.

`linux-omarchy` is not Arch's `linux`. The package carries `0300-btrfs.patch` and `0280-mm-updates.patch` and is built with `-O3`. The warning below fired in `btrfs_init_eb_prealloc()`, which that btrfs patch adds.

#### 2026-10-01 22:48:52 UTC — warning, tainted `[W]` from then on

```
WARNING: mm/page_alloc.c:4819 at __alloc_pages_slowpath.constprop.0+0x146a/0x15d0
current->flags & PF_MEMALLOC
```

Task: `kswapd0/141` on CPU 10.

Call path:

`__alloc_frozen_pages_noprof` → `alloc_pages_bulk_noprof` → `btrfs_alloc_page_array` → `alloc_eb_folio_array` → `btrfs_init_eb_prealloc` → `alloc_extent_buffer` → `btrfs_alloc_tree_block` → `btrfs_force_cow_block` → `btrfs_cow_block` → `btrfs_search_slot` → `btrfs_truncate_inode_items` → `btrfs_evict_inode`

In current `omarchy-pkgs` `pkgbuilds/linux-omarchy/0300-btrfs.patch`, `btrfs_init_eb_prealloc()` allocates extent-buffer folios with `GFP_NOFS | __GFP_NOFAIL` unless the caller asked for nowait. This call was the non-nowait path, from reclaim (`kswapd` has `PF_MEMALLOC`). Upstream `alloc_extent_buffer` already uses those GFP flags; the warning is that this allocation ran in `kswapd`. Please do not treat this as the February 2026 slab-sheaves regression. That stack goes through `allocate_slab` / `refill_objects`. This one does not.

#### 2026-10-02 01:55:56 UTC — order-0 allocation failure while reclaiming into the btrfs swapfile

```
ThreadPoolForeg: page allocation failure: order:0, mode:0xc0de0(GFP_KERNEL|__GFP_HIGH|__GFP_ZERO|__GFP_COMP|__GFP_NOMEMALLOC)
```

cpuset: a docker scope (businessgame-pr2). Path: `swap_cluster_alloc_table` → `folio_alloc_swap` → `shrink_folio_list`.

Swap is a ~31 GiB btrfs swapfile on this same filesystem. `zswap.enabled=0`. `0280-mm-updates.patch` rewrites the vmscan cost accounting this reclaim path uses. This is same-boot memory pressure, not asserted as the cause of the leaf damage.

#### 2026-10-05 11:58 UTC (06:58 CDT) — transaction aborted, remounted read-only

This line was only in the kernel ring. journald's last stored line is 11:57:30 UTC, so it is not in the persisted journal.

```
BTRFS critical (device dm-0): corrupt leaf: root=257 block=1391323873280 slot=2, bad key order, prev (8064999 108 73703424) current (8064487 108 73834496)
BTRFS info (device dm-0): leaf 1391323873280 gen 135191 total ptrs 185 free space 324 owner 257
```

State went to EMA. `btrfs_remount` then refused read-write: "remounting read-write after error is not allowed". The block device itself was not read-only (`ro` 0).

Root 257 is `@home`. Leaf generation 135191 is one past the committed superblock generation seen on the next mount (135190), so this leaf was never committed. A fresh mount from a rescue boot (stock `7.2.3-arch1-3`, not this kernel) replayed the tree log and came up read-write. No new corrupt leaf. Please do not suggest `btrfs check --repair`. The committed tree is the last good transaction.

#### What it is not

- Not an NVMe I/O error. `btrfs device stats` stayed 0 for write, read, flush, corruption, and generation, before and after. The drive's sysfs state was live, and there was no medium error in the log.
- Not a machine check. No Hardware Error / MCE line in this boot's journal. RAM is 32 GB non-ECC, so a bit flip would not be reported. `HardwareCorrupted` is 0 on the rescue boot, which says nothing about the failed boot. Memtest86+ has not been run yet.
- Not the USB backup disk. A different btrfs (`/dev/sdb1`, "Linux Backup") logged `corrupt 21` at boot. That counter is not this filesystem.
- No OOM-killer record for this boot.

Workload at the time: desktop session, Docker, a local GPU model, and a browser. The previous boot on this same kernel ended with hung tasks and an unclean reboot at 2026-10-01 21:01 UTC.

`omarchy-debug` output is not attached. The machine is currently booted from a rescue disk because the normal boot stops at the LUKS prompt with nobody at the keyboard, so I cannot collect it from the affected boot without rebooting blind.

#### Ask

Please check whether `0300-btrfs.patch` (extent-buffer preallocation with `__GFP_NOFAIL`) or `0280-mm-updates.patch` can enter this reclaim path on `7.2.5-3`, and whether a later linux-omarchy build (master is past 7.2.5-3) changes it. If the same stack happens on unpatched mainline, it belongs on linux-btrfs. If it only happens with these patches, it should stay here.