Re: Sleep inside atomic for aarch64, triggered by generic/482

["Darrick J. Wong" <djwong@kernel.org>]

On Sun, Apr 20, 2025 at 08:24:12PM +0930, Qu Wenruo wrote:
> Hi,
> 
> Recently I hit two dmesg reports from generic/482, on aarch64 64K page size
> with 4K fs block size.
> 
> The involved warning looks like this:
> 
> 117645.139610] BTRFS info (device dm-13): using free-space-tree
> [117645.146707] BTRFS info (device dm-13): start tree-log replay
> [117645.158598] BTRFS info (device dm-13): last unmount of filesystem
> 214efad4-5c63-49b6-ad29-f09c4966de33
> [117645.322288] BUG: sleeping function called from invalid context at
> mm/util.c:743
> [117645.322312] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 46,
> name: kcompactd0
> [117645.322325] preempt_count: 1, expected: 0
> [117645.322329] RCU nest depth: 0, expected: 0
> [117645.322338] CPU: 3 UID: 0 PID: 46 Comm: kcompactd0 Tainted: G W  OE
> 6.15.0-rc2-custom+ #116 PREEMPT(voluntary)
> [117645.322343] Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> [117645.322345] Hardware name: QEMU KVM Virtual Machine, BIOS unknown
> 2/2/2022
> [117645.322347] Call trace:
> [117645.322349]  show_stack+0x34/0x98 (C)
> [117645.322360]  dump_stack_lvl+0x60/0x80
> [117645.322366]  dump_stack+0x18/0x24
> [117645.322370]  __might_resched+0x130/0x168
> [117645.322375]  folio_mc_copy+0x54/0xa8
> [117645.322382]  __migrate_folio.isra.0+0x5c/0x1f8
> [117645.322387]  __buffer_migrate_folio+0x28c/0x2a0
> [117645.322391]  buffer_migrate_folio_norefs+0x1c/0x30
> [117645.322395]  move_to_new_folio+0x94/0x2c0
> [117645.322398]  migrate_pages_batch+0x7e4/0xd10
> [117645.322402]  migrate_pages_sync+0x88/0x240
> [117645.322405]  migrate_pages+0x4d0/0x660
> [117645.322409]  compact_zone+0x454/0x718
> [117645.322414]  compact_node+0xa4/0x1b8
> [117645.322418]  kcompactd+0x300/0x458
> [117645.322421]  kthread+0x11c/0x140
> [117645.322426]  ret_from_fork+0x10/0x20
> [117645.400370] BTRFS: device fsid 214efad4-5c63-49b6-ad29-f09c4966de33
> devid 1 transid 31 /dev/mapper/thin-vol.482 (253:13) scanned by mount
> (924470)
> [117645.404282] BTRFS info (device dm-13): first mount of filesystem
> 214efad4-5c63-49b6-ad29-f09c4966de33
> 
> Again this has no btrfs involved in the call trace.
> 
> This looks exactly like the report here:
> 
> https://lore.kernel.org/linux-mm/67f6e11f.050a0220.25d1c8.000b.GAE@google.com/
> 
> However there are something new here:
> 
> - The target fs is btrfs, no large folio support yet
>   At least the branch I'm testing (based on v6.15-rc2) doesn't support
>   folio.
> 
>   Furthermore since it's btrfs, there is no buffer_head usage involved.
>   (But the rootfs is indeed ext4)

Doesn't matter; the block device can create large folios in its page
cache and blkid reading the bdev can create buffer heads.

willy's workaround in:
https://lore.kernel.org/linux-fsdevel/Z_VwF1MA-R7MgDVG@casper.infradead.org/

works enough to make this go away.

--D

> 
> - Arm64 64K page size with 4K block size
>   It's less common than x86_64.
> 
> Fortunately I can reproduce the bug reliable, it takes around 3~10 runs to
> hit it.
> 
> Hope this report would help a little.
> Thanks,
> Qu
>